fix(tests): wait for the workflow detail header before asserting on it - #6730
Merged
shahargl merged 1 commit intoAug 24, 2026
Merged
Conversation
Signed-off-by: chiruu12 <103719146+chiruu12@users.noreply.github.com>
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
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.
Closes #6727.
test_add_workflowasserts onwf-namestraight afterwait_for_url, butwait_for_urlreturns when the URL changes, not when the page has rendered. Until theRSC navigation for
/workflows/{id}comes back,WorkflowDetailHeaderhas no workflowand renders a skeleton, and
data-testid="wf-name"exists only in the branch afterthat. So the locator matches nothing and the failure reads as a text mismatch when the
element is simply absent:
The 5000ms is
page.set_default_timeout(5000)from thebrowserfixture intests/conftest.py:557. On a loaded runner the server render can lose that race, whichis why this fails on whichever database variant happened to be slow rather than on
anything database-specific.
Change
One assertion added before the existing one:
Splitting it keeps the two concerns apart. The new line waits for the heading to attach,
the existing line still asserts on its text under the default timeout. Raising the
timeout on the text assertion instead would work, but it reads as "this text takes 15
seconds to appear", which is not what happens.
15000 matches the existing idiom in this file for a slow load,
test_end_to_end.py:99and
:189. If you would rather have a shared constant, say so and I will add one.Verification
Run against the e2e sqlite compose with the published
keep-apiandkeep-uiimages,down --volumesbetween runs.Holding the RSC navigation for 8 seconds reproduces the CI failure on the unmodified
test:
Same delay, this branch:
Undelayed, this branch passes in 8.75s.
Worth recording, since it sent me the wrong way first: delaying the client fetch at
/backend/workflows/{id}by the same 8 seconds does not reproduce it. The headertakes
initialDataas SWRfallbackData, so the skeleton never appears while thatrequest is in flight. Only the server render can produce the empty state. Details in
the issue.
Not changed
The same
wait_for_url(re.compile("http://localhost:3000/workflows/.*"))followed by animmediate assertion appears at lines 500, 568, 590, 615, 660 and 746. The race is
reachable from all of them, but I have only observed it at 425 and did not want to turn
a one-test fix into a six-site sweep unasked. Happy to do the sweep here or in a
follow-up.