fix(app): prioritize first transcript pages over background reads by kitlangton · Pull Request #57741 · anomalyco/opencode · GitHub
Skip to content

fix(app): prioritize first transcript pages over background reads - #57741

Merged
kitlangton merged 1 commit into
betafrom
message-priority
Oct 21, 2026
Merged

kitlangton merged 1 commit into
betafrom
message-priority

Conversation

@kitlangton

@kitlangton kitlangton commented Oct 21, 2026 •

Copy link
Copy Markdown
Contributor

Problem

The first transcript page still waits behind the previous session's queued Location reads after #57684 removes the form storm and #57679 adds request tiers.

Change

Give unfiltered, cursorless newest-message lists the same read tier as session lists. Writes stay first; paging, user-message indexes, ascending history, and single-message reads keep background priority. Running requests finish normally.

Merge after #57679. This branch is now rebased onto origin/home-loading at 47a10580b6, retaining its queue machinery. The PR base stays beta; once #57679 merges, the diff shrinks to this change: two files, +26/-6 (runtime +11/-5, keeper +15/-1). git merge-tree against home-loading is conflict-free.

The review fix excludes before as well as cursor, type, and ascending order. TurnRail reply previews such as ?limit=25&before=msg_1 stay in the background tier. The existing queue-order test now covers that exact request.

Tab-hover limitation

Tab hover and click both call data.session.message.sync(id). That API carries no priority hint, and the shared sync joins an existing promise even when its fetch is still queued. Inactive-tab first-page prefetch therefore still uses tier 1 and FIFO; hovering several tabs can queue them ahead of the clicked tab. Demoting hover alone could leave the clicked tab joined to a tier-0 queued request. Distinguishing intent and promoting queued work needs a wider change to sync/queue plumbing, so it is deferred.

Paired production measurements before this review repair

Production Chromium on Pro, 180 ms injected latency per request, scrubbed HOME-shaped SQLite history. Alternating order, fresh contexts, one warmup, no live-state reads or writes.

Comparison Pairs Initial message queue median Click to newest paint median
Beta → beta + #57684 + #57679, clean Home click 9 0 → 0 ms 814.8 → 839.7 ms
Beta → both reviewed fixes, switch from 199 idle descendants 7 9,751.7 → 341.7 ms 10,406.3 → 975.7 ms
Both reviewed fixes → both + this change, same loaded switch 9 363.1 → 147.2 ms 1,103.1 → 847.5 ms

Last comparison: queue improves in 8/9 pairs, ties once; paint improves in 8/9. Paired mean saving is 215.5 ms queue (bootstrap 95% interval 117.6–326.9) and 188.6 ms newest paint (81.9–294.7). These are fixture-specific savings, not a live HOME guarantee. The two loaded-switch rows are separate batches and must not be subtracted from each other.

Paired queue and newest-paint measurements

What the original ~212 ms wait contained

Clean Home click with both reviewed fixes: ~182 ms injected latency, ~29 ms headers-arrived to JavaScript callback, ~3 ms dispatch/transport. Actual handler time (~15 ms in this beta fixture) is separate. Queue median is zero. Component medians do not add exactly to the median total. Both fixes changed the old wait metric 226.2→212.2 ms, but the paired spread does not support a reliable clean-open saving.

Messages already start independently of session info and before Location setup. The message-list handler reads the store without booting a Location. This fixture has no auth handshake. Tab hover loads messages after 100 ms; Home rows do not (their prefetch is metadata, and desktop hover loads VCS). No hover changes here.

In the median-priority sample, four already-running requests (MCP resources, two worktree refreshes, references) account for the remaining 147 ms queue wait; skills and forms remain queued behind the initial page.

Verification

  • Request-queue keeper: 12 tests / 42 assertions pass, protecting writes-first, FIFO within read tiers, background paging/indexes, aborts, concurrency and timeouts.
  • Review repair: the new before case fails with the old predicate and passes with the guard. The full request-queue file passes 12 tests / 42 assertions, through foreground HiveMind.
  • Root bun run check: lint passes; typecheck initially stopped on an untracked manual benchmark whose fixture had been archived. Moved that benchmark into the same artifact archive and reran typecheck: 36/36 tasks pass, through foreground HiveMind.
  • Production build and all measured scenario completion checks pass.
  • Reserved client-data and timeline files untouched. No API or durable data changes.
  • Measurement integration head before this change: 5f34b490a4; after: d40f23aec9. Pinned beta: 036d0faea7. Reviewed inputs: fix(app): calm loading state for Home sessions #57679 47a10580b6, fix(app,server): stop subagent form polling from stalling sends #57684 39f173d5b2.
  • Raw evidence: wait-queue.json, wait-switch.json, wait-priority.json, analysis and lossless per-request spans retained in the session-load evidence archive. The first switch run overflowed Chrome's resource timing buffer; queue/product measurements survived. Increased its size for the final comparison; no missing final metrics.

Leave unmerged for review. The large form-storm improvement belongs to #57684/#57679, not this PR.

Review repair and CI

Pushed head dc90e84fed3bf0c1a5ccdf22828aec4caee9d89e. CI run 39608647911 finished after a foreground wait. Linux/Windows builds, unit tests and session-ui component suites pass. App E2E and app component suites fail, including cached-timeline Find/disposal, mobile touch navigation, activity chips, virtualizer reconnect and websearch. Failed-job logs are retained; these failures have not been reproduced on a clean parent, so their attribution remains unresolved. Leave CI-blocked and unmerged, after #57679.

@kitlangton
kitlangton merged commit 1ef252d into beta Oct 21, 2026
9 of 15 checks passed
@kitlangton
kitlangton deleted the message-priority branch October 21, 2026 16:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant