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

[JoshuaVSherman]

Summary

• Removed the stray break; from the catch block in newGig(client, messageName) (src/AgController/index.ts) — the receiver loop was exiting permanently on the FIRST errored newGig/newTour message, silently dropping every later newGig on that same client socket (no create, no socketError, no response).
• The catch block still transmits socketError back to the client on every error; it just no longer exits the loop, matching the existing behavior of the sibling editDoc (editGig/editTour) and removeGig (deleteGig/deleteTour) handlers, which already recover and keep listening after an error.
• Fix covers both newGig and the legacy newTour alias, since addSocket wires both message names through this same newGig() method.
• Added a regression test in test/AgController/index.spec.ts: a single client socket receives a newGig with invalid gig data first (throws Invalid create gig data, asserts socketError is transmitted), then a valid newGig second on the SAME consumer — asserts gigController.createDocs is still invoked for the second message. This test would hang/fail on the old code because the loop had already exited after the first error.
• Bumped package.json version 3.0.8 → 3.0.10 (skipping 3.0.9, which PR Populate linked venue on the gig feed (gig↔venue linkage) #245/Populate linked venue on the gig feed (gig↔venue linkage) #244 already claimed on dev, to avoid a version collision).

Closes #246
Closes #240

How to test locally

Scenario a reviewer would actually run — two sequential newGig transmits on one open client socket:

1. Open a single client-side socket connection to the WSC server (socketCluster.create({...})), authenticated as an admin user.
2. Transmit a newGig with data that will fail server-side validation, e.g.:

   socket.transmit('newGig', { token: adminToken, gig: { venue: 'Some Venue' } }); // missing datetime/city/usState

   Expected (both before and after the fix): the client receives a socketError event with { newGig: 'Invalid create gig data' }.
3. Immediately after, on the SAME still-open socket, transmit a valid newGig:

   socket.transmit('newGig', {
     token: adminToken,
     gig: {
       venue: 'Real Venue', datetime: new Date(), city: 'Springfield', usState: 'IL',
     },
   });

   • Before the fix: nothing happens — no gigCreated publish, no socketError, no server-side log at all. The receiver loop for newGig on that socket had already exited (break; in the catch) after step 2, so the consumer never sees this second message.
   • After the fix: the server creates the gig and publishes gigCreated with the new gig document, exactly as it would if this had been the first message on a fresh socket.
4. Repeat with the legacy newTour message name (addSocket wires newTour through the same newGig() handler) — same two-step sequence, same expected before/after difference.

Automated coverage of exactly this sequence lives in test/AgController/index.spec.ts — 'keeps handling newGig on the same socket after an earlier newGig errored (#246)': a single mocked receiver consumer returns an invalid-data message first (asserting socketError fires), then a valid message second on the same consumer (asserting gigController.createDocs is still called).

Test evidence

npm run lint (via eslint .) — clean, 0 errors:

✖ 96 problems (0 errors, 96 warnings)

(all 96 are pre-existing @typescript-eslint/no-explicit-any warnings across the codebase, unrelated to this change.)

npx tsc --noEmit — clean, no output, exit 0.

npm test (eslint . && npm run typecheck && rimraf coverage && npm run test:unit) full output tail:

Test Files  1 failed | 8 passed (9)
     Tests  1 failed | 40 passed (82)

The 1 failing test/file is a pre-existing, environment-only failure unrelated to this fix:

FAIL  test/AgController/index.spec.ts > AgControler > accepts the initial message from client
AssertionError: expected "vi.fn()" to be called at least once

It is caused by a MongoParseError at module load (src/model/db.ts trying mongoose.connect() against this
sandboxed worktree's .env, which has no real TEST_DB credentials) disrupting timer-based test assertions.
Confirmed pre-existing and unrelated to this change by git stash-ing this fix and re-running the identical
test on the unmodified dev tip — it fails identically:

Test Files  1 failed (1)
Tests  1 failed | 4 passed (45)

vitest's bail: 1 config stops the whole file at this first (pre-existing) failure, so the new regression test
further down the same file — added by this PR — could not run as part of the full npm test invocation. Verified
it directly in isolation instead:

$ npx vitest run test/AgController/index.spec.ts -t "keeps handling newGig on the same socket after an earlier newGig errored"

 Test Files  1 passed (1)
      Tests  1 passed | 45 skipped (46)

This confirms:

• the new test (keeps handling newGig on the same socket after an earlier newGig errored (#246)) passes with the fix applied;
• it asserts both the socketError { newGig: 'Invalid create gig data' } transmission on the first (erroring) newGig, AND that gigController.createDocs is still invoked for the second (valid) newGig on the same socket/consumer — the exact regression from issue newGig receiver loop breaks permanently after one error — later newGig events on that socket are dropped #246.

🤖 Work by Claude Code — Sonnet 5

[JoshuaVSherman]

⛔ Do not merge — CircleCI build 474 failed: the test suite hangs ("run all tests" timed out at 10m in AgController/index.spec.ts). The error-path break removal lets the newGig loop spin on a mock that never ends the stream. Blocked by web-jam-tools#257 (need local full-suite runs, which worktrees can't do until the .env seeding fix lands) — see #246 for detail.