fix: remove the two sources of CI flakiness

[msitarzewski]

CI has been failing intermittently on every push for months, on different Node versions and different steps each time. Two unrelated causes, both fixed at the root rather than papered over.

1. Signaling tests shared peer IDs

Tests 3-8 all registered the same two hardcoded UUIDs, and teardown was ws.close() — fire-and-forget, which only starts the closing handshake. When the next test's register beat the previous socket's cleanup, the server correctly answered already registered and the test timed out waiting for registered. Exactly the CI failure:

[WARN] Peer ID already registered: aaaaaaaa-aaaa-4aaa-8aaa-aaaaaaaaaaaa
FAIL: 8. Spoofed "from" field rejection
  Error: Timeout waiting for message type: registered

The window is too narrow to reproduce on a fast machine, so I reproduced the mechanism deterministically instead — same code path, window held open explicitly rather than raced for:

SHARED peer ID (the old pattern), teardown not yet processed:
  prev test  -> registered
  next test  -> error (Peer ID "aaaaaaaa-..." is already registered)
  => COLLISION -> "Timeout waiting for message type: registered"

UNIQUE peer IDs (the fix), same window:
  prev test  -> registered
  next test  -> registered
  => no collision possible

Every test now mints fresh IDs via randomUUID() (verified 2000/2000 against the server's UUID_V4_REGEX), so the collision is impossible regardless of teardown timing. Teardown also awaits CLOSED so sockets stop accumulating.

The server was never at fault. Duplicate rejection is desired behavior, and test 2 still asserts it.

2. Return feeds were abandoned if the mix-minus bus was slow

web/js/main.js waited out a stagger delay (500ms polite / 2500ms impolite), then checked once for the peer's mix-minus stream. Not ready at that instant → log a warning and give up permanently. No retry existed on that path, so the return feed was never created and the peer silently heard nothing for the rest of the session.

That matches the failure shape: bimodal. When it works the feed arrives in ~7s; when it fails it is still absent at 45s. Not a timing-tolerance problem — more sleep would not have helped, because the app had already stopped trying.

Now polls for up to 10s past the stagger delay, stops quietly if the peer disconnected, and logs an error rather than a warning if the stream genuinely never appears.

3. CI was hiding it

-node tests/test-return-feed.mjs || node tests/test-return-feed.mjs || node tests/test-return-feed.mjs
+node tests/test-return-feed.mjs

PR #4 ("stabilize flaky return-feed test in CI") made it three attempts, any pass. That masked the defect above and made every red X ambiguous — which is a large part of why a red X stopped meaning anything here, and why #12 sat for four weeks without anyone trusting its checks.

Verification, and its limits

• Signaling suite: 15/15 consecutive clean runs, collision mechanism proven and disproven as above.
• Return-feed fix: not verified locally. The Playwright browser build for this repo would not finish installing on my machine, and the flake only manifests under CI contention anyway. CI is the honest verifier here, which is exactly why the retry mask had to come off in the same change.

If the return-feed test now fails, that is real signal rather than noise, and the right response is to keep digging — not to restore the mask. I would rather it fail visibly than pass three-times-lucky.

🤖 Generated with Claude Code