fix(desktop): a broken release opens an error window instead of hanging#25903

🟠 High

https://github.com/pingdotgg/t3code/blob/f1aaca775c62789b8335f7a8318177faac21905f/apps/desktop/src/backend/DesktopBackendPool.ts#L163

When handleBackendReady fails, this still publishes Ready, so DesktopStartupRecovery closes the recovery window without a main window and leaves the user without recovery controls. The catch runs before Effect.andThen; move the Ready update before the catch so it runs only after successful window creation while errors remain absorbed.

Fixed in 0f80f608f4. The Ready update now runs before the catch, so it is set only after the main window is created. Window errors are still caught, so readiness still resets the restart counter.

🟡 Medium app/DesktopStartupRecovery.ts:55

After recoverFailedInstall reports an install failure, this still resolves to Update because downloadedVersion remains set, leaving the user with the same Update button and no installer error or manual-download fallback. runAction also discards the install result; add a failed-install recovery offer that surfaces the updater error and provides a manual download action.

Not changing this. After an install fails during the session, the button retries the install. That matches the remote update flow, which also treats a download with an install error as installable. If an update installs but does not apply, the next launch records notAppliedVersion, and this window then offers the last working version or the releases page instead of the update. A separate failed-install offer with its own download link adds UI for a rare case that retry already covers.

This adds an arbitrary Electron error message to structured log annotations; it may contain unbounded paths or other sensitive text. Could you log a bounded category/stage instead and retain the underlying error as a cause rather than copying error.message into annotations?

^{Posted via Macroscope — Effect Service Conventions}

Fixed in 0e49edb6d0. The warning now logs only errorTag.

Logging the entire cause as an annotation can serialize arbitrary failure text and backend output. Could you annotate a normalized failure category here instead, keeping the cause in the Effect failure channel for diagnostics?

^{Posted via Macroscope — Effect Service Conventions}

Fixed in 0e49edb6d0. The cause now goes in as the log's cause through Effect.logWarning(message, cause), not as an annotation. The only annotation is the component name.

External image Minor · Functional Correctness · Quick win

Decode streamed output with a streaming decoder.

outputDecoder.decode(chunk) runs without { stream: true }. A multibyte UTF-8 character split across two chunks decodes as U+FFFD in the captured tail. That tail is shown in the recovery window and copied by Copy details.

A single TextDecoder is also shared by stdout and stderr. Adding { stream: true } to that shared decoder would mix partial bytes from the two streams. Use one decoder per stream. Create the decoders again in onStarted so a previous run's partial bytes do not leak into the next run.

Based on learnings: decode streamed child-process chunks with a streaming decoder, because per-chunk decoding corrupts multibyte characters split across chunk boundaries.

Source: Learnings

✅ Addressed in commits 0f80f60 to cb32491

Fixed in cb32491844. Each of stdout and stderr now has its own streaming decoder, and both are created again on each run. The crash-loop test now splits é across two stderr chunks. It fails without the fix.

@t3dotgg The supplied code confirms the fix: stdout and stderr use separate decoders with { stream: true }, and onStarted recreates both decoders for each run. This addresses the finding.

✅ Review thread resolved.

_{You are interacting with an AI system.}

startup.reason can include the lower-level error.message passed through finalizeRun and scheduleRestart, so logging it as a structured annotation can expose arbitrary defect text or paths. Could you annotate a bounded failure category instead and keep the exact diagnostic in the underlying cause/output channel? No single-hunk fix is sufficient because the failure needs a normalized category at its source.

^{Posted via Macroscope — Effect Service Conventions}

Fixed in 20dad371fb. I removed the reason annotation from this warning. The backend manager already logs each failure's reason, so this was a duplicate.

🟡 Medium app/DesktopStartupRecovery.ts:204

When an update is already downloaded while a background check is running, clicking Update silently does nothing: updates.install supplies no expected version, so installDownloadedUpdate rejects the active check and the rejected result is ignored. Call updates.installPrepared(current.version) so installation waits for the check.

Fixed in 20dad371fb with your suggestion. Update now calls updates.installPrepared(current.version), so it waits for a running check instead of being refused.

🟠 High backend/DesktopBackendManager.ts:952

Truncating outputTail with slice can leave a lone surrogate, causing encodeURIComponent in DesktopStartupRecovery.render to throw URIError and prevent the recovery page from loading. Truncate by code point so non-BMP characters at the boundary remain intact.

Fixed in a1903242b7. The tail is now cut and then passed through toWellFormed(), so a cut through a surrogate pair leaves U+FFFD and not a lone surrogate. The crash-loop test now places the cut inside an emoji and checks isWellFormed(). It fails without the fix.