[Bug] PR panel shows "Could not load pull requests" on the first open after a turn

[simonsteiner]

What happened

Clicking a pull request link in a thread opens the PR panel in the right sidebar, but the first open after launching the app often shows Could not load pull requests — All fibers interrupted without error with a Retry button. Retry always loads the PR. Opening PRs later in the same session works.

Diagnosis

Two bugs combine. The server hands a request an interrupted result, and the client stores that interrupt as a permanent error.

1. The client cancels and resends detail right after the panel opens (by design, harmless alone).
The PR panel's detail query refreshes on the pullRequests.subscribeRefreshes signal (makeRefreshOnSignal in packages/client-runtime/src/state/runtime.ts). That stream is SubscriptionRef.changes(pullRequestRefreshes) filtered to revision > 0 (apps/server/src/pullRequest/PullRequestService.ts, subscribeRefreshes). So once the server has completed any agent turn since it started, the stream emits its current value as soon as it is subscribed. When the panel is the first PR reader to mount, it subscribes as it opens. The first value arrives about 40 ms later and restarts the query: the client sends Interrupt for the first detail request and a second identical detail request. This happened on every one of 20+ attempts.

2. The server lets the resent request join the read that is being torn down.
detail reads are coalesced through an effect/Cache (detailCache in PullRequestService.ts). When the only caller is interrupted, Cache's entry await interrupts the lookup fiber once the awaiter count drops to 0. The entry is removed from the map only after that fiber exits (the observer in Cache.get), and stopping the gh processes it is running takes a few ms. A request that reaches Cache.get during that window finds the still-present entry, joins the dying fiber, and exits with a bare Interrupt. The RPC server sends that back as the request's result.

3. The client turns that interrupt into a sticky error.
The atom stores Failure(Interrupt) and never retries. useEnvironmentQuery (apps/web/src/state/query.ts) formats it as the error string ("All fibers interrupted without error"), writableQueryFamily (packages/client-runtime/src/state/pullRequests.ts) passes it through, and PullRequestDetailPanel renders PullRequestsUnavailableState with Retry. Commands already ignore interrupt-only failures (isAtomCommandInterrupted); queries don't.

Whether step 2 hits depends on timing: the resent request must reach Cache.get inside the few ms while gh is stopping. On my machine it does often: the desktop app on Windows with the WSL backend, a real database, and gh against github.com. In an isolated dev server with an empty database it never hit in 19 attempts, although step 1 happened every time. Widening the window (below) makes it deterministic.

Possible fixes, for whoever picks this up:

• Server: don't hand an entry whose lookup is being interrupted to a new caller. For example, remove it from the map when the last awaiter leaves, or retry Cache.get when the joined exit is interrupt-only and the caller itself wasn't interrupted. The same Cache pattern backs activity, preview, list and diff reads.
• Client: treat an interrupt-only Failure as still pending, or retry it, instead of an error.
• Optionally, don't refresh on the refresh stream's initial value, only on changes after subscribing.

Steps to reproduce

In the app (intermittent, depends on timing):

1. Start T3 Code and let an agent turn complete in any thread (the refresh revision is 0 until then).
2. Without having opened any PR panel in this session, click a GitHub PR link in a thread whose project matches the repository. The PR must not have been read by the server in the last ~15 s.
3. The PR panel sometimes shows "Could not load pull requests — All fibers interrupted without error". Retry loads it.

Deterministic, in an isolated dev server (vp run dev with a fresh --home-dir):

1. Widen the teardown window by adding Effect.onInterrupt(() => Effect.sleep("250 millis")) to the detailUncached(...) pipe in the detailCache lookup in PullRequestService.ts. This only simulates a slower gh shutdown; it does not change which code path runs.
2. Add a project inside a GitHub repo and let an agent reply with a PR link from that repo.
3. In a fresh browser session, click the link. The panel fails on 4 of 4 attempts. The attached video shows this setup.

Deterministic, as unit tests (no timing involved):

// apps/server: effect/Cache hands a dying lookup to the next caller
import { assert, it } from "@effect/vitest";
import * as Cache from "effect/Cache";
import * as Deferred from "effect/Deferred";
import * as Effect from "effect/Effect";
import * as Exit from "effect/Exit";
import * as Fiber from "effect/Fiber";

it.effect("a read arriving while an abandoned lookup shuts down gets its interrupt", () =>
  Effect.gen(function* () {
    const started = yield* Deferred.make<void>();
    const stopped = yield* Deferred.make<void>();
    let lookups = 0;
    const cache = yield* Cache.make({
      capacity: 10,
      lookup: (_: string) =>
        ++lookups === 1
          ? // Like `gh`, the first lookup takes a moment to stop once interrupted.
            Effect.yieldNow.pipe(
              Effect.andThen(Deferred.succeed(started, undefined)),
              Effect.andThen(Effect.never),
              Effect.onInterrupt(() => Deferred.await(stopped)),
            )
          : Effect.succeed("fresh"),
    });
    const first = yield* Cache.get(cache, "detail").pipe(Effect.forkChild);
    yield* Deferred.await(started);
    yield* Fiber.interrupt(first).pipe(Effect.forkChild({ startImmediately: true }));
    const second = yield* Cache.get(cache, "detail").pipe(
      Effect.forkChild({ startImmediately: true }),
    );
    yield* Deferred.succeed(stopped, undefined);
    // Fails: Failure(Cause([Interrupt])), lookups === 1
    assert.deepStrictEqual(yield* Fiber.await(second), Exit.succeed("fresh"));
  }),
);

// packages/client-runtime: an interrupt reply becomes a permanent failure with no retry.
// Uses a harness like makeTestRuntime in src/state/pullRequests.test.ts.
it.effect("detail recovers when the server answers a read with an interrupt", () =>
  Effect.scoped(
    Effect.gen(function* () {
      let calls = 0;
      const client = {
        [WS_METHODS.pullRequestsSubscribeRefreshes]: () => Stream.never,
        [WS_METHODS.pullRequestsDetail]: () =>
          ++calls === 1 ? Effect.interrupt : Effect.succeed({ ...reference, title: "ok" }),
      } as unknown as WsRpcProtocolClient;
      const { atoms, registry } = yield* setup(client);
      const detail = atoms.detail({ environmentId: TARGET.environmentId, input: reference });
      // ...mount and wait for the atom to stop waiting...
      // Fails: final is Failure(Cause([Interrupt])) after calls === 1; nothing retries.
      expect(AsyncResult.isSuccess(registry.get(detail))).toBe(true);
    }),
  ),
);

Version

0.0.43-nightly.20260928.2375 (desktop, WSL backend); also reproduced on main at d15210c

Environment

Windows 11 (10.0.26200) desktop app with the WSL2 backend (kernel 6.18.33.2), gh 2.101.0, effect 4.0.0-rc.115

Evidence

# Real session, server trace (ws.rpc.pullRequests.*), first PR opened after launch:
16:25:52.261 ws.rpc.pullRequests.subscribeRefreshes  (stream opened)
16:25:52.263 ws.rpc.pullRequests.detail  81 ms  Interrupted  (client abort; its gh processes killed)
16:25:52.340 ws.rpc.pullRequests.detail   3 ms  Interrupted  "interrupted by fiber #14087"
             # #14087 is the detailCache lookup fiber created by the first request
             # (its gh children are #14088..#14094); the second request only ran canonicalRef
16:25:52.426 ws.rpc.pullRequests.activity 962 ms Success
16:25:54.503 ws.rpc.pullRequests.detail 681 ms  Success  (user pressed Retry)

# Isolated dev repro, client WebSocket frames (ms since page start):
 9653 click PR link
 9804 → Request 16 pullRequests.subscribeRefreshes
 9804 → Request 17 pullRequests.detail {"repository":"pingdotgg/t3code","number":13190,...}
 9840 → Interrupt 17
 9840 → Request 19 pullRequests.detail {"repository":"pingdotgg/t3code","number":13190,...}
10091 ← Exit 17 Failure [Interrupt fiberId 4921]
10163 ← Exit 19 Failure [Interrupt fiberId 5054]   # the dying detailCache lookup
10169 panel: "Could not load pull requests / All fibers interrupted without error"
13684 click Retry → loads

Video (isolated dev server, widened window as described above): first click on the link → error panel → Retry → loads.

pr-panel-interrupted-first-open.mp4

Related issues

• [Bug]: PR detail/activity is re-fetched for every displayed PR on each focus, visibility change and 5-minute tick (merged PRs included), exhausting the GitHub GraphQL quota #13496: PR detail and activity are re-fetched on focus, visibility and the 5-minute tick. It uses the same refresh machinery, but it's about request volume, not this interrupt.
• [Bug]: Fall back to the integrated browser when pull requests cannot load #14041: fall back to the integrated browser when pull requests can't load. It covers the list error state, not why detail fails here.
• fix(preview): failed tabs no longer sit as a blank floating panel #7236 (PR): a failed browser preview no longer sits as a blank floating panel. That's the browser-preview path, not the PR panel.

None covers this interrupt race.

Fix applied or workaround

None applied. Workaround: press Retry.

Filed by

Claude Opus 5.5 (Claude Code, running in T3 Code), investigated with t3 triage's playbook

[juliusmarminge]

Triage

Confirmed on current main. This is a real first-open failure, not a gh or auth problem. Retry works because the dying cache entry is already gone.

The cancel and the error are separate:

1. subscribeRefreshes is SubscriptionRef.changes(pullRequestRefreshes) filtered to revision > 0 (PullRequestService.ts). A SubscriptionRef replays its current value, so the first reader after any completed turn receives that revision immediately. Atom.makeRefreshOnSignal refreshes on that update, which aborts the in-flight detail request and sends the same read again. That extra read is what opens the window. A successful second read would still paint the panel.

2. detailCache only drops an entry after the lookup fiber exits (Cache.ts: the map removal is in the fiber observer, and Entry.await interrupts the lookup when the last caller leaves). Stopping gh keeps that entry in the map for a few milliseconds. The resent detail joins that fiber and comes back as an interrupt-only failure. DETAIL_CACHE_TTL is 15 seconds, which matches the "not read in the last ~15s" condition. Activity, preview, list, and diff use the same cache shape.

3. The client stores that failure. useEnvironmentQuery squashes an interrupt-only cause to All fibers interrupted without error, and PullRequestDetailPanel renders PullRequestsUnavailableState. Commands already ignore interrupt-only results via isAtomCommandInterrupted. These queries do not. The first open has no previous success, so writableQueryFamily cannot hide it.

Do not fix this by treating every interrupt as pending in useEnvironmentQuery. #6233 did that and was closed because #8117 already retries queries across a dropped session. A live session that receives an interrupt-only RPC result is a different case.

The race closes in the cache: a caller that was not itself interrupted should not observe a lookup that is shutting down. Retry Cache.get when the joined exit is interrupt-only, or remove the entry when the last awaiter leaves. Skipping the refresh stream's replayed current value would stop this particular cancel and is worth doing, but other refreshes can still hit the same window.

Not a duplicate of #13496 (refresh volume) or #14041 (list fallback).

[simonsteiner]

Reproduced on macOS as well, and there it's not intermittent.

Setup: macOS 26.6 (Apple Silicon), Node 24.18, gh 2.100, main at d15210cd3d. Isolated vp run dev with a fresh --home-dir, one completed turn, then a fresh headless Chrome context per attempt, each clicking a pingdotgg/t3code PR the server hadn't read yet. The server was unmodified, with no widened teardown window.

Result: the first open failed on 16 of 16 attempts. Retry loaded the PR every time.

• The client sends the Interrupt and the resent request in the same millisecond, 20–33 ms after the first request.
• On the server, the second ws.rpc.pullRequests.* span starts about 1 ms before the first one ends, and every time it ends as Interrupted. On this machine the window is always hit.
• activity fails in practice, not only in theory. Both detail and activity came back interrupt-only in 13 attempts. Only activity failed in 2, where the detail loaded but the panel showed "Could not load pull request activity". Only detail failed in 1. This supports fixing it in the cache rather than only for detail.

Both unit tests from the issue body also fail on macOS as described.

[video: first open → "Could not load pull requests — All fibers interrupted without error" → Retry loads]

mac-pr-panel-interrupted.mp4

[saphid]

Routing: Do not open a duplicate. #14113 already reports this exact failure and includes real-client traces and videos. Its maintainer triage confirms the problem and prefers fixing the cache race. Use this draft as a current-main evidence supplement and keep implementation within that agreed problem; the earlier service-scoped, always-complete proposal is not implied approval.

Environment and verification limits

Research date: 2026-10-03. Fetched origin/main successfully; target: 7ff2eabf56. Local research host: macOS / Darwin 25.5.0 arm64, Node v24.12.0, gh 2.94.0. Main pins Effect 4.0.0-rc.115. This lane used read-only source comparisons and existing evidence; it did not launch a server, browser, desktop app, or live forge checkout. Historical regression results below are explicitly historical, not fresh runtime reproductions on this SHA. Source fingerprints and exact verification scope are in verification.json.

Exact reproduction on current main

1. Run the fetched revision in an isolated development home with a project whose GitHub PR can be read using the server's existing CLI authentication. Keep the PR unread by the server for at least its 15-second detail-cache TTL; use a fresh PR if needed.
2. Complete one agent turn in any thread, so pullRequests.subscribeRefreshes has a revision greater than zero.
3. Open that PR's detail panel for the first time in the client session, for example by clicking its PR link in the matching project's thread.
4. Inspect RPC events: the first detail read is cancelled when the refresh stream replays its current revision; a second request for the same reference begins while the first lookup's subprocess cleanup is still running. The failure is timing-dependent, so an attempt outside that cleanup interval may succeed.
5. When the panel shows the failure, press Retry. Once the old cache entry is removed, the new request succeeds.

Deterministic service reproduction, without a timing sleep: the existing P02 regression fixture gates a lookup and its interruption finalizer with Deferreds; cancel its only caller, begin a second read for the same key while cleanup is blocked, then release the gates and join the second caller. The second caller receives a bare interrupt rather than a successful value. Fixture names: keeps a shared detail lookup alive when its only caller cancels and keeps shared repository detection alive when its only caller cancels. These fixture tests were executed on the earlier baseline, not rerun here. The issue also supplies a smaller Cache-level test.

Actual versus expected

Actual: a request that has not itself been cancelled joins an already-interrupting cached lookup. The PR panel can show “Could not load pull requests — All fibers interrupted without error”; activity can fail similarly. Retry works after cleanup. Expected: cancellation affects the departing caller; a later, live caller receives a successful fresh/shared read or a meaningful lookup error, not another caller's interrupt.

User impact

First-open PR review fails and requires manual Retry. The existing report includes real Windows/WSL and macOS reproductions; the macOS commenter observed detail and/or activity failure in 16 of 16 unmodified-server attempts on the older revision. Those rates are not claimed for today's main.

Current-main verification

• PullRequestService.detail still calls Cache.get(detailCache, key) without a cache-interruption recovery path; its detail-cache/read block is byte-for-byte unchanged from the baseline used for P02.
• VcsDriverRegistry.ts, RepositoryIdentityResolver.ts, and the vendored Cache source are also unchanged. Installed Effect rc.115 retains the same last-awaiter interruption behavior; the repository patch does not change Cache.
• Cache removes an interrupted entry in its fiber completion observer. EntryImpl.await interrupts the lookup when its awaiter count reaches zero, leaving the documented cleanup window.
• Current main's added checks cache and stale-data handling do not remove the first-read race: a missing last-good detail still takes the shared cache read directly. Do not describe every cache read as patched or every cancellation as failing.

Source: apps/server/src/pullRequest/PullRequestService.ts; .repos/effect-smol/packages/effect/src/Cache.ts; apps/server/src/vcs/VcsDriverRegistry.ts.

Minimal proposed fix scope — no implementation

Fix cancellation/rejoin handling at the shared cache boundary, following the maintainer's triage: a live caller must not inherit an abandoned lookup's interrupt. Establish consistent scope for the PR read caches and repository lookups that use this cache behavior, with deterministic Deferred-gated regressions. Preserve caller cancellation and shutdown semantics. Prefer the cache-layer solution over scattered wrappers; do not include unrelated client error policy or refresh UX. If service-owned reads that continue after all callers leave are proposed instead, explicitly agree on that subprocess/rate-limit tradeoff and avoid fiber overhead on cache hits.

Evidence available

• Existing #14113, its maintainer confirmation, and unmodified macOS reproduction provide externally available real-client evidence.
• Historical P02-before.log: exit 1, two cancellation regressions fail on the earlier baseline. P02-after-final.log: exit 0, 182 tests pass on the earlier proposed branch.
• Extraction report and independent review describe that branch and its tradeoffs; they do not establish current-main implementation approval.
• Fresh evidence: read-only source comparisons in verification.json, and full report readback in existing-issue-14113.json. No new real-client recording was made in this lane.

🤖 Generated with Claude Code

[TonybynMp4]

This race also hits after a mutation, not only on a first open.

I hit it resolving a review thread from the PR panel. The server publishes a refresh and the panel refetches activity. About 30 ms later, the panel's own refresh after the mutation cancels that read and sends it again. The resent read joins the lookup that is shutting down and fails with the first read's interrupt. The server log shows Interrupt(4603), the cancelled request's fiber, not the second request's.

Since the panel already holds a successful activity value, nothing shows an error. The panel just keeps the old state and the thread stays unresolved until the next periodic refresh or a manual one. Any mutation followed by a refetch can leave stale data on screen this way.

I hit it from a Resolve button I added to the Summary tab on my fork. The Code tab's Resolve does the same thing (mutation, then onRefresh), so it should hit this too on main, though I haven't checked that path. A local fix of the same shape as #14122 makes the resolved state appear right away. #14654 covers this path as well, since it fixes it in Cache for every read.