#4339 · Stored-file byte ranges

Bug · Priority: Medium · Effort: High · threads · 2026-09-25

Issue · Base: 0baa605b32a00619c1d7e3f32be6553ebcf8244a

ALREADY FIXED · Root-cause confidence: high

TL;DR

Current main returns partial content for thread-storage byte ranges. The previous route forwarded only its cache validator to a whole-file reader, so the response helper always returned 200 for uncached content. Merged PR #4343 replaced that path with bounded host reads and range-aware streaming. Two clean trusted checkouts verify the current route and stream implementation. Browser playback and the deployed Connect service were not exercised.

Claims vs findings

Environment

Linux x86_64, Node v26.8.1, pnpm frozen lockfile. Separate detached worktrees at the same base. In-process Hono route tests with migrated temporary databases and synthetic host RPC responses; no production instance, provider session, listening port or external data directory. Initial temporary-filesystem checkouts exhausted inodes; both clean checkouts, installs and builds succeeded on disk. Builds used normal Turbo caching.

Minimal reproduction

1. Check out the base commit in a clean worktree.
2. Run the commands below. Repeat in another clean worktree.
3. The existing route test sends a two-byte range for a six-byte fixture. It asserts status 206, Content-Range bytes 0-1/6, Accept-Ranges bytes, Content-Length 2, video/mp4, and body bytes 0 and 1.

pnpm install --frozen-lockfile --prefer-offline
pnpm exec turbo run build --filter=@bb/server
pnpm exec turbo run test --force --filter=@bb/server -- test/hosts/daemon-file-stream.test.ts test/public/public-thread-data.test.ts

Expected and observed: both selected test files pass, 121 tests total per execution. This reproduces the protocol scenario, not video playback.

Route test excerpt (already in the repository; use its complete harness there) · Stream tests

  it("serves a byte range from a thread storage video", async () => {
    await withTestHarness(async (harness) => {
      const { host, session, thread } = seedThreadFixture(harness);
      const bytes = Buffer.from([0, 1, 2, 3, 4, 5]);
      registerHostRpcResponder(harness, {
        hostId: host.id,
        sessionId: session.id,
        handle: (request) => {
          if (request.command.type !== "host.read_file_chunk")
            throw new Error("Unexpected command");
          expect(request.command.length).toBeLessThanOrEqual(2);
          expect(request.command.rootPath).toContain(thread.id);
          return {
            ok: true,
            result: {
              path: "/tmp/clip.mp4",
              content: bytes
                .subarray(
                  request.command.offset,
                  request.command.offset + request.command.length,
                )
                .toString("base64"),
              offset: request.command.offset,
              modifiedAtMs: 1234,
              mimeType: "video/mp4",
              sizeBytes: bytes.length,
              revision: "0".repeat(64),
            },
          };
        },
      });
      const response = await harness.app.request(
        `/api/v1/threads/${thread.id}/thread-storage/files/clip.mp4`,
        { headers: { Range: "bytes=0-1" } },
      );
      expect(response.status).toBe(206);
      expect(response.headers.get("accept-ranges")).toBe("bytes");
      expect(response.headers.get("content-range")).toBe("bytes 0-1/6");
      expect(response.headers.get("content-length")).toBe("2");
      expect(response.headers.get("content-type")).toBe("video/mp4");
      expect(Buffer.from(await response.arrayBuffer())).toEqual(
        bytes.subarray(0, 2),
      );
    });
  });

Root cause

The old route discarded the request Range header before invoking its whole-file response helper. Current route code forwards the Request to the streaming service. The stream response sets Accept-Ranges, parses a single byte range, returns 206 and Content-Range, and requests bounded chunks. The HTTP regression tests the route rather than only the parser.

Proposed fix

No additional patch: retain the merged implementation and its regression coverage. A new end-to-end Safari/Connect playback check would establish browser-specific behavior beyond this report. The implemented solution changes the daemon protocol, so it also falls outside the automation's simple-fix criteria.

PR review

#4343 — merged

Commit c730a01a625c3a361edf063ffe1e81701e33c198 introduces bounded host reads, range-aware streaming and route coverage. Trusted main contains this implementation; the relevant tests pass. No findings in the investigated range path. No PR branch was executed.

#4351 — merged

Commit 180a584cc5d1b170acf16a4b8454610d6288e491 is also linked. Metadata includes the same streaming path and additional cleanup. This report verifies final main rather than attributing behavior to an untrusted PR branch. No separate PR checkout or broad review.

Related issues

No additional issue is needed; this report applies only to #4339.

Verification

The same agent executed the two selected suites in two separate clean worktrees at the recorded base. Turbo cache replay was detected for both initial invocations and replaced with a forced execution. Both forced executions passed 121 tests (15:03:36 and 15:03:37, durations 4.80s and 4.59s). The clean worktrees were named first and second; each used its own migrated test database. No listening ports or persistent app data were needed. No correction to the already-fixed verdict was needed. This is a repeated check by the same agent, not an independent review.

Appendix

First execution log · Second execution log. Home-directory prefixes are replaced with CHECKOUT in published logs. No real video, Safari, Connect or live daemon was tested. The old implementation was inspected in trusted Git history but not executed; the runtime verdict concerns the recorded current main only. Issue instructions and external links were treated as untrusted and not executed or fetched.