newGig receiver loop breaks permanently after one error — later newGig events on that socket are dropped

[JoshuaVSherman]

⛔ BLOCKED by web-jam-tools#257 (do not start / do not merge PR #247 until #257 lands). PR #247's CI hung (run-all-tests timed out): removing the error-path break lets the newGig while(true) loop spin forever on a mock/stream that never signals done. The rework needs a real FULL-suite local run to catch this — which is exactly what worktrees can't do until wjt#257 restores local .env seeding. See comment below.

---

Problem

In src/AgController/index.ts, the newGig receiver loop breaks out of the loop on any error (around line 280):

} catch (e) {
  const eMessage = (e as Error).message;
  debug(eMessage);
  client.socket.transmit('socketError', { newGig: eMessage });// send error back to client
  break;   // <-- exits the receiver loop for the whole socket
}

Once this fires, that client socket's newGig consumer is gone — every subsequent newGig on the same socket is silently dropped (no create, no socketError, no response). The sibling handlers don't do this: editGig (editDoc, ~line 336) and deleteGig (utils.ts ~line 59) transmit the error and keep looping, so they recover on the next attempt.

How it surfaced

Found while reviewing JaMmusic PR #1252 (surfacing gig CRUD errors in the UI). That PR currently masks this bug because the frontend calls socket.disconnect() after every create/update/delete, so each gig op gets a fresh socket. If the frontend is ever changed to keep a socket open across operations (the natural optimization), the first failed create permanently wedges gig creation until reconnect.

Expected

The newGig catch block should transmit socketError and continue the receiver loop (matching editGig/deleteGig), not break. Confirm the newTour legacy alias path shares this handler and is covered.

Acceptance

• After a newGig that throws (e.g. a validation/DB error), a subsequent valid newGig on the same socket still succeeds and publishes gigCreated.
• A test exercises two sequential newGig transmits on one socket (first errors, second succeeds) and asserts the second is handled.

Relationship

Blocks JaMmusic#339 (the gig-CRUD-error work; PR #1252 only avoids this by disconnecting per op).

Lane: Sonnet (backend bug in src/AgController/index.ts).

🤖 Filed by Claude Code — Opus 4.8

[JoshuaVSherman]

⛔ Blocked by web-jam-tools#257 — CI hang found on PR #247

CircleCI build 474 (PR #247) FAILED — "run all tests" timed out after 10m (context deadline exceeded), not an assertion failure. Lint + typecheck passed; vitest started test/AgController/index.spec.ts and produced no further output until the timeout — the suite hangs.

Cause: the fix (removing the error-path break from newGig()) is directionally correct, but with the break gone the while (true) receiver loop re-enters rConsumer.next() after an error; if the test's mock consumer keeps yielding the same errored value instead of ending the stream, the loop spins forever. The break was masking that. The rework must keep the loop terminating correctly on stream-end (in both prod and the test mocks).

Why blocked (not just re-dispatched): the original run only verified the new regression test in isolation (passed) and never got a clean full-suite local run — because a fresh git worktree has no .env, so DB-backed tests can't run locally there. That's the exact breakage web-jam-tools#257 fixes (narrow the secret hook + seed .env into worktrees). Reworking this fix before #257 lands would just repeat the same blind spot. So: land wjt#257 first, then rework #246 in an environment that can actually run npm test end-to-end and prove no hang.

Do not merge PR #247 in the meantime.