test(node-ui): stabilize the flaky WM→SWM promote e2e (60s migration wait)#1462
Closed
Jurij89 wants to merge 2 commits into
Closed
test(node-ui): stabilize the flaky WM→SWM promote e2e (60s migration wait)#1462Jurij89 wants to merge 2 commits into
Jurij89 wants to merge 2 commits into
Conversation
…wait) The `wm-swm-vm-ui-cycle › promotes WM → SWM via the UI and the triples actually migrate` real-node devnet test flakes: the promote UI reports success (the "No triples were promoted" no-op assertion passes), but the follow-on `countRootInSharedMemory > 0` check times out at 20s with Received: 0. The WM→SWM store migration lands in oxigraph asynchronously after the promote request is accepted, and under a loaded CI devnet it can exceed the 20s poll window — so the assertion races store propagation rather than testing the migration. Same symptom, not code-related: identical code passes and fails across runs (e.g. green on branch CI, red on the merge commit), and the whole window that "introduced" it touches only PCA node-UI, nothing in the promote/SWM/SPARQL path. Bump the migration-landing poll from 20s → 60s with [1000,2000,5000] intervals, matching the VM-publish wait already in this same file (line ~262). Test-only; makes the migration assertion robust to CI store-propagation lag without weakening it (a promote that never migrates still fails). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01M3swmeQGT8WGttaZsp1NQJ
Address the review suggestion: the WM→SWM migration wait and the SWM→VM publish wait are the same "wait for the async store migration to land in oxigraph" policy, previously duplicated as an inline 60s literal in both places. Extract a single `STORE_PROPAGATION_WAIT` constant and use it for both, so the coupling is enforced in code (not just prose) and the two propagation waits can't drift. Kept it a plain object (not `as const`): Playwright's `toPass` expects a mutable `intervals: number[]`, which a readonly tuple would not satisfy. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01M3swmeQGT8WGttaZsp1NQJ
otReviewAgent
left a comment
otReviewAgent
left a comment
There was a problem hiding this comment.
Review Agent completed this review and found no issues.
Contributor
Author
|
Closing — this timeout bump does not fix the flake. #1462's own CI failed with the 60s timeout ( |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Stabilizes the flaky
wm-swm-vm-ui-cycle › promotes WM → SWM via the UI and the triples actually migratereal-node devnet e2e test, which currently reddensKosava: node-ui e2e (Playwright real-node devnet)on main and every open PR branched from it.It's a timing flake, not a code regression:
countRootInSharedMemory > 0times out at 20 s withReceived: 0(all 3 retries).Fix: bump the migration-landing poll
20s → 60swith[1000, 2000, 5000]intervals — matching the VM-publish wait already present in the same file (line ~262). Test-only. It does not weaken the assertion: a promote that never migrates still fails (it just gives the async store migration realistic headroom under CI load).Related
Files changed
packages/node-ui/e2e/specs/devnet/wm-swm-vm-ui-cycle.devnet.spec.tstoPasstimeout20s → 60s([1000,2000,5000]intervals) + comment on the async SWM-propagation cause.Test plan
Kosava: node-ui e2e (Playwright real-node devnet)goes green (the previously-flaky spec passes with the migration allowed to land within 60 s).