[Bug]: Stable web client + nightly server renders Usage as all zeros, notice blames the server

[estdysfanktion]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/web

Steps to reproduce

1. Run a current t3 serve (anything after Add hourly past-24-hour usage view #6170, which bumped USAGE_CONTRACT_VERSION to 4) and pair it with app.t3.codes.
2. Open Usage on app.t3.codes.
3. Watch the server side: server.getUsageSummary succeeds and returns a populated summary with contractVersion: 4.

Expected behavior

The page shows the totals the environment just reported. If a version guard has to drop the data, the notice should say the web client is behind, not blame the server.

Actual behavior

Every figure on the page renders as 0, with a small notice per device: " runs an older server version and is excluded from totals."

Two things combine to cause this:

1. app.t3.codes is serving a frontend built before Add hourly past-24-hour usage view #6170 (2026-08-11). The deployed assets/index-*.js has no "Past 24 hours" view, its usage window key is only {sinceDay, untilDay, timeZone} (no resolution/sinceTime/untilTime), and its minified merge call is BHe(a.flatMap(GHe), 3), i.e. mergeUsage(answered, 3). It expects usage contract 3.
2. The stale guard is strict equality. usageMerge.ts does summary.contractVersion === expectedContractVersion, so a newer server fails the check exactly like an older one. Every current server replies with 4, every device gets pushed into staleEnvironments, and the merge returns the empty summary. The page renders all zeros and the notice claims the (newer) server is older.

So any user on a recent nightly who opens Usage on the hosted web app sees $0.00 / 0 tokens across the board, while their server logs show successful getUsageSummary calls. Verified end to end on my setup: the server's scan cache holds ~128M tokens over 30 days and the RPC returns them; the deployed client discards the reply.

Impact

Major degradation or frequent failure

Version or commit

Server: 0.0.34-nightly.20260819.1133. Hosted frontend: whatever app.t3.codes served on 2026-08-25 (chunks index-DjUtAiF9.js / textarea-rLmLQHqI.js).

Environment

Linux server (t3 serve on 127.0.0.1:3773) paired via T3 Connect; Firefox 153 on Linux against app.t3.codes. Same result regardless of provider; transcripts present for both Claude Code and Codex.

Logs or stack traces

# server trace: the summary request the web app then discards
{"name":"ws.rpc.server.getUsageSummary","durationMs":26.5,"exit":{"_tag":"Success"}}

# deployed app.t3.codes bundle (index-DjUtAiF9.js), merge call site:
... c=BHe(a.flatMap(GHe),3) ...   # mergeUsage(answered, 3)

# same bundle, stale filter:
... i.summary.contractVersion===t?n.push(i):r.push(i.environmentId) ...

Workaround

Use a client that matches the server's version: the web client the server itself hosts (e.g. http://127.0.0.1:3773) or a current desktop build. Both expect contract 4 and show correct figures.

Suggested fixes beyond redeploying the hosted app: make the guard tolerate or at least correctly describe a newer server (contractVersion > expected means the client is behind), and word the notice accordingly. Related: #6045 covers the separate case where an offline remembered device holds the page on the skeleton forever.

[tris203]

If you are running a nightly server you can change the hosted to client to run the nightly build in settings

[estdysfanktion]

Correction to my framing above: this is not a stale deployment. The hosted app has an "Update track" setting (Stable / Nightly) and I was reading the Stable track's bundle. Switching the hosted client to Nightly (Settings -> Update track) loads a contract-4 client and Usage shows correct figures again. Confirmed working.

So the reproducible bug is narrower but still real: Stable web client + nightly server silently zeroes the Usage page. The strict contractVersion === expected check drops the newer server's data, and the per-device notice says the server "runs an older server version", which points the user in exactly the wrong direction. Nothing suggests switching the update track.

Suggested fixes, updated:

1. When contractVersion > expected, say the web client is behind and link the Update track setting (or prompt to switch/reload) instead of blaming the server.
2. Consider rendering totals for matching devices even when others are version-mismatched; today one mismatched device direction can zero the whole page for single-device accounts.

Title updated to match.