(Draft) Bug: diff viewer returns "fleet-bridge request failed: {}" in some cases

[FireSquid6]

More investigation needed to get consistent reproduces. This doesn't happen all the time. In the console, it appears that the diff text is being returned.

See #20 and #15 for the relevant issues and MR that added this uncaught bug.

[FireSquid6]

@claude do some investigation on what could be causing this bug and in what cases this reproduces. It is flaky--sometimes I'll get it and refresh and it will work again. Sometimes I will have a perfectly working diff viewer but it will break after a refresh.

Every time, I can see that the request is going through and that the diff information is being returned from the route.

[claude]

Claude finished @FireSquid6's task in 6m 45s —— View job

---

Investigation: fleet-bridge request failed: {} in the diff viewer

• Read the diff-viewer request path end-to-end (DiffView → EdenFleetBridge → bridge → ship)
• Trace where edenError can stringify to {}
• Identify the specific condition that reproduces it
• Check test coverage for that condition
• Write up findings (no fix implemented — this was requested as investigation only)

Most likely root cause: an empty diff is treated as an error

packages/fleet-bridge/src/fleet-manager.ts:699-704 (getWorkspaceDiff) proxies the ship's diff response through the generic call() helper:

async getWorkspaceDiff(repo: string, name: string, options: DiffOptions): Promise<string> {
  const conn = this.routeFor(repo, name);
  return this.call<string>(conn, () =>
    conn.client.workspaces({ repo })({ name }).diff.get({ query: options }) as Promise<EdenResult<string>>,
  );
}

call() (fleet-manager.ts:1068-1106) has this unconditional check:

if (result.data === null) {
  throw new BridgeError(`ship "${conn.name}" returned no data`, 502, opts?.ambiguousEmptyResponse);
}

The actual diff producer, git.diff() in packages/git-bun/src/git.ts:163-188, legitimately returns an empty string whenever there's nothing to diff — e.g. a clean working tree (getWorkspaceDiff's default "working" mode is { range: "HEAD", includeUntracked: true }, see packages/fleet-client/src/lib/diff/diff-target.ts:27-28). That's a completely normal, successful outcome (the UI already handles it: DiffView shows "No changes to show." when files.length === 0).

The problem is what happens to that empty string on the wire. Elysia/Eden's response pipeline (and many fetch layers generally) tend to collapse an empty/no-content body into null rather than "" when unwrapping { data, error } — so a 200 response with an empty body ends up as result.data === null, which call() can't distinguish from "the ship returned nothing." That turns a perfectly valid empty diff into a thrown BridgeError('ship "..." returned no data', 502).

This is corroborated by:

• Asymmetric handling nearby: createWorkspace (fleet-manager.ts:766-774) is the only other caller that acknowledges this exact ambiguity, passing { ambiguousEmptyResponse: true }. getWorkspaceDiff doesn't opt into that — and even if it did, call() still unconditionally throws either way; the flag only affects whether the resulting error is later treated as retry-safe, not whether an empty diff is treated as valid.
• Zero test coverage of a real empty-body round trip: packages/fleet-bridge/tests/helpers.ts:149-150 stubs the ship's diff response as `diff for ${repo}/${name}` — always non-empty — and bypasses the real Eden HTTP fetch/parse layer entirely (it's an in-memory fake, see makeFakeClient). packages/fleet-ship/tests/api.test.ts and fleet-bridge/tests/api.test.ts likewise only exercise non-empty diff text. So a genuinely empty diff has never been exercised through the real Eden serialization path at either hop (client→bridge or bridge→ship).

Why it's flaky specifically for you

This would explain the pattern you're seeing almost exactly:

• The request always does go through and the ship does return valid diff data — it's just that "valid" sometimes means "", and that's the case that breaks.
• If something (e.g. an agent) is actively committing/writing to the workspace between refreshes, the working tree flips between "has uncommitted changes" (diff succeeds) and "clean" (diff throws) — matching "sometimes I'll get it and refresh and it will work again" and "a perfectly working diff viewer... will break after a refresh."
• It's not unique to "working tree" mode either — "vs branch" without includeWorking, or "last N commits" where those commits net out to no changes, are also legitimate empty-diff cases.

To reproduce deterministically: open the diff viewer for a workspace with a fully clean git status (no uncommitted/untracked changes) — that should trigger it every time, if this theory is right.

Caveat

I wasn't able to run bun install/bun test in this sandbox (tool permissions blocked it), so I couldn't empirically confirm Eden's exact empty-body → null behavior against the pinned versions (@elysiajs/[email protected], [email protected]) or reproduce it live. The code-level evidence above (the unconditional null-check, the legitimately-empty diff producer, and the complete absence of empty-body test coverage) is strong, but I'd recommend confirming with a quick manual test (diff a clean workspace) or a unit test that drives a real Eden client against a real empty-body response before committing to a fix.

Suggested direction (not implemented — happy to do this in a follow-up if you'd like)

getWorkspaceDiff shouldn't route through call()'s blanket "no data = error" check, since ""/null is an expected, successful outcome for this specific endpoint. It should treat a null/empty result as "" rather than throwing.

[FireSquid6]

@claude The error occurs often when the diff is not empty. Frequently, I will have a working diff (full) and then refresh to see that it is now giving an error. The network tab shows the diff text coming through just fine.

[claude]

Claude finished @FireSquid6's task in 5m 23s —— View job

---

Investigation: fleet-bridge request failed: {} — follow-up (error occurs even with non-empty diffs)

• Read new report: error happens even when diff is non-empty, and flaky across refreshes with no data change
• Re-examine request path: DiffView → EdenFleetBridge → bridge route → fleet-manager.call() → ship
• Look specifically at how edenError / error body serializes to {}
• Check for race conditions / concurrency issues
• Identify most likely root cause(s) distinct from the "empty diff" theory
• Write up findings

The new report rules out the previous "empty diff" theory

You're right that it contradicts what I found before — empty-diff-as-null only explains a specific, deterministic case (clean working tree). It can't explain "full working diff → refresh → error with no change to the repo," so there's a second, more general mechanism at play.

Found it: edenError silently discards the real error whenever it's a raw exception

packages/fleet-client/src/data/eden.ts:50-53:

function edenError(error: { status?: unknown; value?: unknown }): Error {
  const detail = error.value === undefined ? error : error.value;
  return new Error(`fleet-bridge request failed: ${JSON.stringify(detail)}`);
}

This is a classic JS footgun: JSON.stringify(someError) evaluates to "{}" whenever someError is an Error/DOMException/TypeError instance, because message/name/stack are non-enumerable own properties on those objects — JSON.stringify only serializes enumerable ones. So any time the Eden call's error.value ends up being a raw thrown exception (rather than a parsed JSON error body like { error: "..." }), this code throws Error: fleet-bridge request failed: {} — completely swallowing whatever the actual problem was.

This exact pattern is duplicated in two other places, both susceptible to the same collapse:

• packages/fleet-bridge/src/fleet-manager.ts:1093-1098 (call()'s error mapping, bridge→ship)
• packages/fleet-cli-kit/src/client.ts:46-51 (unwrap(), used by the CLI)

Why this fits the new report much better

• Independent of diff content — this path fires on any Eden call whose underlying fetch throws (network reset, aborted/truncated body stream, connection-pool race), regardless of whether the diff itself is empty or a full multi-file patch. Matches "occurs often when the diff is not empty."
• Flaky, refresh-sensitive — transport-level hiccups (a stale/reused keep-alive socket, a dropped connection mid-response) are inherently intermittent and have nothing to do with the data itself, matching "full working diff → refresh → error → refresh again → works."
• "Network tab shows the diff text coming through fine" — the DevTools preview reflects what bytes arrived over the wire, which can look complete even when the JS-side fetch/stream consumption throws afterward (e.g. a body-stream/framing hiccup after headers land), or the user is comparing against a different, successful retry request rather than the one that actually failed. Either way, a 200 looking fine in the Network tab doesn't rule out the JS promise rejecting during body read.

The request path has two proxy hops that could produce such a raw exception: browser → fleet-client's proxyToBridge (packages/fleet-client/src/index.ts:97-120, which does return await fetch(target, init) — passing the upstream Response's body stream straight through without buffering) and bridge → ship inside fleet-manager.call(). Neither fleet-client nor fleet-bridge sets an explicit AbortController/timeout anywhere in the request path (checked), so this isn't a deliberate abort — it points to an actual transport-level flake (e.g. a stale pooled connection, or a hiccup re-streaming an upstream response through a second Bun.serve hop) rather than application logic.

What's still true from the earlier investigation

The empty-diff → null → thrown BridgeError issue in getWorkspaceDiff (fleet-manager.ts:699-704, call() at 1102-1104) is a real, separate, fully deterministic bug — it just isn't what's causing this report, since it wouldn't produce {} (that path's message is ship "..." returned no data, not {}), and only fires on empty diffs.

Caveat

I couldn't run bun install/bun test in this sandbox (tool permissions), so I couldn't reproduce a live network exception or confirm exactly which hop throws it. The JSON.stringify(Error) → "{}" mechanism itself is directly verifiable from the code and JS semantics alone, independent of that — it's a real bug regardless of what specific network condition triggers it.

Suggested direction (not implemented — investigation only, happy to do a follow-up)

Fix edenError (and its two siblings) to check for value instanceof Error and use .name/.message instead of blindly JSON.stringify-ing it. That won't fix whatever underlying transport flake is happening, but it turns an opaque, undebuggable {} into an actual reason (e.g. TypeError: fetch failed / AbortError: The operation was aborted), which would let you — or a future investigation — pin down the real root cause instead of guessing at it blind.