Sign up
View stargazersSign up

Server self-update hides the root cause of a failed release download behind "Could not prepare t3@<version>"#33233

opened1d agobyGgrenmango51

What happened

The desktop app offered to update my linked Ubuntu server to the nightly the desktop was running. The update failed showing only "Server update failed: Could not prepare t3@0.1.8-nightly.20261109.4399." with Retry/Dismiss buttons. Nothing said why it failed or whether retrying was safe.

Diagnosis

The server's trace shows the update died in cloud.pinned_runtime.ensure_installed while fetching the release checksums: GitHub returned a transient HTTP 504 for the SHA256SUMS asset. The PinnedRuntimeInstallError cause chain (step "downloading the t3 release checksums", caused by HttpClientError: 504 GET ) is preserved in the trace, but cloud.server_self_update.update wraps the whole prepare phase into ServerSelfUpdateError: Could not prepare t3@., discarding the step and the status code. The user-facing message therefore gives no hint that (a) the failure was a transient network/CDN error and (b) clicking Retry is safe, since no partial state persists (staging is cleaned via Effect.ensuring, and an incomplete version dir is removed on the next attempt). The same asset returned HTTP 200 minutes later. Suggestion: surface the install step and, for HttpClientError, the status code and host in the user-facing message, and/or word transient HTTP failures (5xx, timeouts) as retryable.

Steps to reproduce

  1. Have a linked remote server on an older build than the desktop.
  2. Trigger the server update from the desktop while the SHA256SUMS release asset request fails with a non-404 error (e.g. intercept https://github.com/pingdotgg/t3code/releases/download/*/SHA256SUMS and return 504).
  3. The desktop shows only "Server update failed: Could not prepare t3@."

Version

Server 0.1.8-nightly.20261107.4340 (the build that produced the error); desktop 0.1.8-nightly.20261109.4399. Triage run from desktop 0.1.8-nightly.20261109.4399.

Environment

Server: Ubuntu Linux x64, t3 server 0.1.8-nightly.20261107.4340, service-managed. Client: T3 Code Desktop 0.1.8-nightly.20261109.4399 on Windows 11 (10.0.26300), Node v24.22.1.

Evidence

shell
1cloud.pinned_runtime.ensure_installed -> Failure:
2 PinnedRuntimeInstallError: Pinned runtime install failed while downloading the t3 release checksums.
3 [cause]: HttpClientError: StatusCode: non 2xx status code
4 (504 GET https://github.com/pingdotgg/t3code/releases/download/v0.1.8-nightly.20261109.4399/SHA256SUMS)
5
6cloud.server_self_update.update -> Failure:
7 ServerSelfUpdateError: Server update failed: Could not prepare t3@0.1.8-nightly.20261109.4399.
8 at failWith (<home>/.t3/runtime/versions/0.1.8-nightly.20261107.4340/t3:153069:98)
9
10Same asset re-fetched from the server minutes later: HTTP 200 in 0.23s.

#21922 (t3 update ignores HTTPS_PROXY, unexplained ECONNRESET) and #28198 (opaque SocketReadError on update preflight, closed) share the "opaque update error" theme but have different root causes and fixes.

Fix applied or workaround

Clicked Retry after the transient 504 cleared; the asset then downloaded with HTTP 200. No machine changes needed; the updater cleans up partial installs itself.

Filed by

Droid (Factory) running Kimi K3, via t3 triage