cultmesh-ts test: queued provider registers observed from creation (RUDP replaced-generation flake) #70

Merged

libby merged 1 commit from libby/rudp-queue-test-unhandled-rejection into main 2026-11-09 19:32:06 +00:00

Conversation 0 Commits 1 Files changed 1 +7 -4

libby commented 2026-11-09 15:50:16 +00:00

Member

Copy link

Verdict: flaky test, not a provider defect

a replaced RUDP generation drops operations queued behind an active handler created two connection.register() promises and attached no handler until the end of the test. The test sets operationTimeoutMs: 100. Neither call can be answered (the first handler is gated, the second is queued behind it, and the generation is closed), so both settle only by the client's operation timeout or connection.close(). If the test body takes longer than 100 ms, the timeout rejects an unobserved promise (CultMesh provider operation provider.register timed out), and node:test reports "generated asynchronous activity after the test ended". The provider is behaving correctly: the pending operation times out on schedule.

Timeouts: client operationTimeoutMs (test: 100 ms, provider default 5000, owner CultMeshProviderRudpTransport); connectTimeoutMs (default 2000, unused by the test); test waitFor limit 1000 ms; a 20 ms sleep after releasing the gate. The test asserts only server-side handlerCalls, so it has no reason to depend on the client timeout.

Evidence

• PR #68 run 499 (job 1762): the test took 191 ms on the runner, failed with exactly this message; 1 of 266 tests failed.
• Main's cultmesh-portability runs (829 and the PR runs 835, 843, 819, 809) never reached the test: they die at pwsh missing or git checkout failure. Run 499 is the first run to execute it, so there is no passing history on main, nor a failing one.
• Local, unmodified test: 20/20 pass idle (~37 ms), 20/20 under 16 busy loops, 14/20 under 64 busy loops (6 failures, all the timeout message above).
• Deterministic repro: the unmodified test with operationTimeoutMs: 1: 0/5 pass.
• With this change: 1 ms variant 5/5, 64 busy loops 20/20 (at 100 ms; the committed test now uses 1 ms so the race is always exercised).

Change

Test only: observe first/second at creation (.then(() => undefined, () => undefined)), and set operationTimeoutMs: 1 so the guard is deterministic rather than load-dependent. No timeout was raised.

🤖 Generated with Claude Code

## Verdict: flaky test, not a provider defect `a replaced RUDP generation drops operations queued behind an active handler` created two `connection.register()` promises and attached no handler until the end of the test. The test sets `operationTimeoutMs: 100`. Neither call can be answered (the first handler is gated, the second is queued behind it, and the generation is closed), so both settle only by the client's operation timeout or `connection.close()`. If the test body takes longer than 100 ms, the timeout rejects an unobserved promise (`CultMesh provider operation provider.register timed out`), and node:test reports "generated asynchronous activity after the test ended". The provider is behaving correctly: the pending operation times out on schedule. Timeouts: client `operationTimeoutMs` (test: 100 ms, provider default 5000, owner `CultMeshProviderRudpTransport`); `connectTimeoutMs` (default 2000, unused by the test); test `waitFor` limit 1000 ms; a 20 ms sleep after releasing the gate. The test asserts only server-side `handlerCalls`, so it has no reason to depend on the client timeout. ## Evidence - PR #68 run 499 (job 1762): the test took 191 ms on the runner, failed with exactly this message; 1 of 266 tests failed. - Main's `cultmesh-portability` runs (829 and the PR runs 835, 843, 819, 809) never reached the test: they die at `pwsh` missing or git checkout failure. Run 499 is the first run to execute it, so there is no passing history on main, nor a failing one. - Local, unmodified test: 20/20 pass idle (~37 ms), 20/20 under 16 busy loops, 14/20 under 64 busy loops (6 failures, all the timeout message above). - Deterministic repro: the unmodified test with `operationTimeoutMs: 1`: 0/5 pass. - With this change: 1 ms variant 5/5, 64 busy loops 20/20 (at 100 ms; the committed test now uses 1 ms so the race is always exercised). ## Change Test only: observe `first`/`second` at creation (`.then(() => undefined, () => undefined)`), and set `operationTimeoutMs: 1` so the guard is deterministic rather than load-dependent. No timeout was raised. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

libby added 1 commit 2026-11-09 15:50:16 +00:00

cultmesh-ts test: observe queued provider registers from creation so a client timeout is not an unhandled rejection ... b55521d50d

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>

libby merged commit aff69c2914 into main 2026-11-09 19:32:06 +00:00

libby referenced this pull request from a commit 2026-11-09 19:32:07 +00:00

Merge pull request 'cultmesh-ts test: queued provider registers observed from creation (RUDP replaced-generation flake)' (#70) from libby/rudp-queue-test-unhandled-rejection into main

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

GameCult/CultLib!70

No description provided.