Pre-existing integration test failures: concurrency.pg.test.ts (ENOENT) and postgres.test.ts (Buffer/Uint8Array)

[Hazzng]

Discovered during end-to-end verification of PR #12 (multi-tenant Postgres routing). These failures pre-date PR #12 — verified by checking out HEAD~2 (before the CodeRabbit fixes) and main, both reproduce. Tracked separately so they don't block the multi-tenant work.

1. src/api/__tests__/integration/concurrency.pg.test.ts — ENOENT on every test

Symptom

13 of 17 tests fail when run against real Postgres + Redis. Each one throws ENOENT: sandbox <id> not found and the route returns 500.

Root cause

The test makes raw HTTP calls without first POSTing to /v1/sandboxes to create the sandbox in the SessionManager pool:

const sbId = newId(); // just generates a UUID
const results = await Promise.all(
  Array.from({ length: N }, (_, i) =>
    app.request(`/v1/sandboxes/${sbId}/files/home/user/shared.txt`, {
      method: "PUT", ...
    }),
  ),
);

But every file route in src/api/routes/files.ts uses sessionManager.withExistingSession(...) (lines 111, 172, 200, 251, 301, 343), which throws ENOENT when the sandbox is not in the pool. The test is asserting 204 on a route that requires a pre-existing session.

The test was likely written when the file routes used withSession (auto-create) and was not updated when they switched to withExistingSession.

Reproduction

docker run -d --name pg-test -e POSTGRES_PASSWORD=test -p 5432:5432 postgres:16
docker run -d --name redis-test -p 6379:6379 redis:7
sleep 3
PGPASSWORD=test psql -h localhost -U postgres -c "CREATE DATABASE vfs_test"
for f in src/fs/sql-fs/migrations/postgres/*.sql; do
  PGPASSWORD=test psql -h localhost -U postgres -d vfs_test -f "$f"
done
DATABASE_URL=postgres://postgres:test@localhost:5432/vfs_test \
DATABASE_DIRECT_URL=postgres://postgres:test@localhost:5432/vfs_test \
REDIS_URL=redis://localhost:6379 \
  pnpm exec vitest run src/api/__tests__/integration/concurrency.pg.test.ts

Fix options

• A: Add a POST /v1/sandboxes to materialize the session before each scenario.
• B: Switch the test's makePgEnv to mount routes that use withSession (e.g., a thin test router) so sandboxes auto-create on first PUT.
• C: Lift the helper that materializes sessions into a per-test setup hook.

Option A best matches what the deployed API actually does and is the smallest change.

---

2. src/fs/sql-fs/integration/postgres.test.ts — Buffer ≠ Uint8Array under Vitest deepEqual

Symptom

13 tests fail with assertions like:

expected Buffer[ 1, 1, 1, 1, ... ] to deeply equal Uint8Array[ 1, 1, 1, 1, ... ]

Root cause

postgres.js returns bytea columns as Node Buffer instances, while the test fixtures use Uint8Array literals. Although Buffer extends Uint8Array, Vitest's toEqual uses strict prototype equality and treats them as different types.

Reproduction

DATABASE_URL=postgres://postgres:test@localhost:5432/vfs_test \
DATABASE_DIRECT_URL=postgres://postgres:test@localhost:5432/vfs_test \
  pnpm exec vitest run src/fs/sql-fs/integration/postgres.test.ts -t "creates a file inode with content_sha256"

Fix options

• A: Wrap expect(...) comparisons with Buffer.from(actual) on both sides, or normalize via new Uint8Array(actual.buffer, actual.byteOffset, actual.byteLength).
• B: In the dialect, return Uint8Array consistently by wrapping the Buffer from postgres.js (e.g., new Uint8Array(row.data)). This keeps the API contract type-correct (SqlDialect.getBlob is typed Uint8Array).
• C: Use .toEqual(expect.arrayContaining(...)) or Buffer.compare-based custom matcher.

Option B aligns the runtime type with the declared interface and benefits any consumer that does instanceof Uint8Array checks.

---

Both issues are independent of multi-tenant routing and isolated to test code (option B for #2 is a one-line dialect change).