fix(tests): finish the public build before closing the popup; widen the messages loading-state wait - #14595
Conversation
…he messages loading-state wait Nightly 31907290063 (main @ b40b405) failed exactly two Playwright shards. Windows 24/70 - messages.a11y "scans the named loading state": the expect after `page.goto("/settings/messages")` used the default 5s. The trace shows goto returning at `load`, then auto_login (1.6-3.0s) -> whoami -> config -> the lazy settings route; the messages query mounted 7.0s / 7.5s after goto, 1.4s / 1.7s after the expect gave up. The aria snapshot at failure was the app-level "Loading..." page, not SessionView's status. Use TIMEOUTS.standard, which the identical held-response loading scan in knowledge-bases.a11y already uses. Linux 41/70 - publish-flow: the spec sent a message in the shareable playground popup and closed it 30ms later, while the public build was still in flight. Aborting that request mid-write made the backend terminate its aiosqlite connections under cancellation; the trace + backend log show a ~60s window where every SQLite writer stalled (the un-publish PATCH never answered, the retry's auto_login hung 34s+, the sibling worker's build took 71s instead of 0.66s) while reads kept answering in ms. Wait for the build to finish (Stop visible -> hidden via the shared sendPlaygroundMessage helper) before closing the popup, which also proves the published playground completes a run rather than merely starting one. Verified locally against the full Playwright stack: both tests pass.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
WalkthroughThe PR updates two frontend tests. The accessibility test uses an explicit standard timeout. The publish-flow test uses ChangesFrontend test updates
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to The tests now wait for the messages loading state and for the public build to finish before closing the popup, reducing flaky failures without changing product behavior. No actionable merge-blocking risk remains beyond normal checks. Possibly related PRs
Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 9✅ Passed checks (9 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
✅ Test Coverage AdvisorNo source changes detected without accompanying tests. Thanks for keeping coverage up! 🎉
|
Summary
Nightly 31907290063 (main @ b40b405, first nightly after #14589) failed exactly two Playwright shards. Both are test-side, both diagnosed from the blob-report traces.
Windows 24/70 —
messages.a11y.spec.ts"scans the named loading state"expect(getByRole('status', {name: 'Loading'})).toBeVisible()right afterpage.goto("/settings/messages")used the default 5s. The trace showsgotoreturning atload(18–24s Vite module storm), thenauto_login(1.6–3.0s) →whoami→config→ the lazy settings route; the messages query mounted 7.0s / 7.5s after goto — 1.4s / 1.7s after the expect gave up. The aria snapshot at failure was the app-levelLoading...boot page, not SessionView's status. Now usesTIMEOUTS.standard, which the identical held-response loading scan inknowledge-bases.a11yalready uses.Linux 41/70 —
publish-flow.spec.tsThe spec sent a message in the shareable-playground popup and called
newPage.close()30ms later, while the public build was still in flight. Aborting that request mid-write made the backend terminate its aiosqlite connections under cancellation, and the trace + backend log show a ~60s window where every SQLite writer stalled while reads kept answering in ms:PATCH /flows/{id}sent 0.5s after the close never answered (→toBeChecked({checked:false})failed);GET /auto_loginhung 34s+ so the app never booted (→mainpage_titletimeout);fresh start playgroundbuild started 0.2s earlier took 71s vs 0.66s for the identical send moments before;Exception terminating connection <aiosqlite …>× 3 withCancelledError … via BaseHTTPMiddleware call_next, thenTask was destroyed but it is pending!for_terminate_graceful_close()at 20:51:25 — right when the stall cleared (GC).Fix: run the message through the shared
sendPlaygroundMessage(newPage, "Hello", { surface: "shareable" }), which waits for the Stop button to appear and clear before returning, so the popup is only closed after the build completes. That removes the abort-mid-write trigger from this spec and also proves the published playground actually completes a run rather than merely starting one.Not addressed here (backend follow-up): the underlying leak looks like a SQLAlchemy
terminate()↔ aiosqlitestop()/close()ordering race under persistent cancellation — the shielded graceful-close task nulls_connectionbefore the busy worker thread reachesclose_and_stop, which then skipssqlite3.close(), leaving an open write transaction alive until gen-2 GC. Real users closing a tab mid-build can hit the same stall; happy to write that up as an issue.Both files are identical on
release-1.12.0, so this cherry-picks cleanly.Test plan
npx biome checkclean on both specs;tscclean over both specs (temp config —tsconfig.json'sincludeskipstests/)messages.a11y "scans the named loading state"✓ 34.8s,publish-flow "user should be able to publish a flow"✓ 43.7s🤖 Generated with Claude Code
Summary by CodeRabbit