fix(recorder): attach rpc observer before navigation in lazy-capture test - #359
Conversation
…test (closes #355) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe lazy-capture integration test now uses ChangesRecorder lazy-capture test
Estimated code review effort: 1 (Trivial) | ~5 minutes Possibly related issues
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
ESLint install failed. For unrecoverable errors, disable the tool in CodeRabbit configuration. Comment |
lazy-capture.it.test.tscalledobserveRpc(page)inside the test body, aftergetExtensionTestApihad already navigated the page. Playwright'spage.on('websocket')only fires for sockets created after the listener attaches, so the observer had no guaranteed claim on the shared rpc socket. Switched torpcObserverFor(page), which returns the observeropenObservedPageinstalls beforepage.goto— the same one-line change the whiteboard drag-batching test took in #349. Dropped the trailingobserver.dispose(): the observer is now the page-scoped shared one and must outlive the test (whiteboard does the same).Mechanism: the luck hypothesis was wrong, but it is luck
Probed with a temporary
socketCount()log, comparing the late observer against the pre-attached one on the same page:Both observers report one socket and the same flush calls. So there is no
ReconnectingWebSocketsecond socket — the page opens exactly one rpc socket over its whole life. The real mechanism is that the socket is opened lazily, afterpage.goto(waitUntil: 'domcontentloaded')resolves and after the test body's first statements run. The late attach caught it by pure timing margin. That is still luck: it is a race between the extension client's connect and the first line of the test, and it flips toexpected 0 to be greater than 1the day connect gets faster. The probe log was removed before commit.Proof
TURBO_CONCURRENCY=1 VITEST_MAX_FORKS=1 pnpm turbo run test --concurrency=1 --filter=@conciv/extension-recorder— 122/122 tests passed.lazy-capture.it.test.tsrun 3x standalone — 2/2 tests passed on every run.format:checkgreen.fallow audit --changed-since mainverdictpass, zero introduced.Pre-existing flake spotted, not fixed here (out of scope)
Independently of this change,
useRecorderTestApi'safterAll(() => api.dispose())intermittently exceeds vitest's 30shookTimeout, failing the file while every test in it passes:Observed on the untouched
panel-stream.it.test.tsduring the suite gate, and on a pre-fix probe run oflazy-capturebefore any behavioral edit — so it predates this PR. Worth its own issue againstpackages/extension-testkitteardown.Closes #355
🤖 Generated with Claude Code
Summary by CodeRabbit