fix(tests): wait for the workflow detail header before asserting on it

[chiruu12]

Closes#6727.

test_add_workflow asserts on wf-name straight after wait_for_url, but
wait_for_url returns when the URL changes, not when the page has rendered. Until the
RSC navigation for /workflows/{id} comes back, WorkflowDetailHeader has no workflow
and renders a skeleton, and data-testid="wf-name" exists only in the branch after
that. So the locator matches nothing and the failure reads as a text mismatch when the
element is simply absent:

AssertionError: Locator expected to contain text 'Example Console Workflow'
Actual value: <element(s) not found>
- LocatorAssertions.to_contain_text with timeout 5000ms

The 5000ms is page.set_default_timeout(5000) from the browser fixture in
tests/conftest.py:557. On a loaded runner the server render can lose that race, which
is 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:

expect(page.get_by_test_id("wf-name")).to_be_visible(timeout=15000)

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:99
and :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-api and keep-ui images,
down --volumes between runs.

Holding the RSC navigation for 8 seconds reproduces the CI failure on the unmodified
test:

DELAYING: http://localhost:3000/workflows/80d9510b-...?_rsc=1d3c8
DELAYING: http://localhost:3000/workflows/80d9510b-...?_rsc=o0tvy
E AssertionError: Locator expected to contain text 'Example Console Workflow'
E Error: element(s) not found
E - waiting for get_by_test_id("wf-name")
1 failed in 31.21s

Same delay, this branch:

1 passed in 30.64s

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 header
takes initialData as SWR fallbackData, so the skeleton never appears while that
request 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 an
immediate 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.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[shahargl]

lgtm

[chiruu12]

Closes#6727.

test_add_workflow asserts on wf-name straight after wait_for_url, but
wait_for_url returns when the URL changes, not when the page has rendered. Until the
RSC navigation for /workflows/{id} comes back, WorkflowDetailHeader has no workflow
and renders a skeleton, and data-testid="wf-name" exists only in the branch after
that. So the locator matches nothing and the failure reads as a text mismatch when the
element is simply absent:

AssertionError: Locator expected to contain text 'Example Console Workflow'
Actual value: <element(s) not found>
- LocatorAssertions.to_contain_text with timeout 5000ms

The 5000ms is page.set_default_timeout(5000) from the browser fixture in
tests/conftest.py:557. On a loaded runner the server render can lose that race, which
is 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:

expect(page.get_by_test_id("wf-name")).to_be_visible(timeout=15000)

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:99
and :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-api and keep-ui images,
down --volumes between runs.

Holding the RSC navigation for 8 seconds reproduces the CI failure on the unmodified
test:

DELAYING: http://localhost:3000/workflows/80d9510b-...?_rsc=1d3c8
DELAYING: http://localhost:3000/workflows/80d9510b-...?_rsc=o0tvy
E AssertionError: Locator expected to contain text 'Example Console Workflow'
E Error: element(s) not found
E - waiting for get_by_test_id("wf-name")
1 failed in 31.21s

Same delay, this branch:

1 passed in 30.64s

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 header
takes initialData as SWR fallbackData, so the skeleton never appears while that
request 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 an
immediate 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.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[shahargl]

lgtm

[chiruu12]

Closes#6727.

test_add_workflow asserts on wf-name straight after wait_for_url, but
wait_for_url returns when the URL changes, not when the page has rendered. Until the
RSC navigation for /workflows/{id} comes back, WorkflowDetailHeader has no workflow
and renders a skeleton, and data-testid="wf-name" exists only in the branch after
that. So the locator matches nothing and the failure reads as a text mismatch when the
element is simply absent:

AssertionError: Locator expected to contain text 'Example Console Workflow'
Actual value: <element(s) not found>
- LocatorAssertions.to_contain_text with timeout 5000ms

The 5000ms is page.set_default_timeout(5000) from the browser fixture in
tests/conftest.py:557. On a loaded runner the server render can lose that race, which
is 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:

expect(page.get_by_test_id("wf-name")).to_be_visible(timeout=15000)

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:99
and :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-api and keep-ui images,
down --volumes between runs.

Holding the RSC navigation for 8 seconds reproduces the CI failure on the unmodified
test:

DELAYING: http://localhost:3000/workflows/80d9510b-...?_rsc=1d3c8
DELAYING: http://localhost:3000/workflows/80d9510b-...?_rsc=o0tvy
E AssertionError: Locator expected to contain text 'Example Console Workflow'
E Error: element(s) not found
E - waiting for get_by_test_id("wf-name")
1 failed in 31.21s

Same delay, this branch:

1 passed in 30.64s

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 header
takes initialData as SWR fallbackData, so the skeleton never appears while that
request 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 an
immediate 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.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[shahargl]

lgtm

[chiruu12]

Closes#6727.

test_add_workflow asserts on wf-name straight after wait_for_url, but
wait_for_url returns when the URL changes, not when the page has rendered. Until the
RSC navigation for /workflows/{id} comes back, WorkflowDetailHeader has no workflow
and renders a skeleton, and data-testid="wf-name" exists only in the branch after
that. So the locator matches nothing and the failure reads as a text mismatch when the
element is simply absent:

AssertionError: Locator expected to contain text 'Example Console Workflow'
Actual value: <element(s) not found>
- LocatorAssertions.to_contain_text with timeout 5000ms

The 5000ms is page.set_default_timeout(5000) from the browser fixture in
tests/conftest.py:557. On a loaded runner the server render can lose that race, which
is 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:

expect(page.get_by_test_id("wf-name")).to_be_visible(timeout=15000)

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:99
and :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-api and keep-ui images,
down --volumes between runs.

Holding the RSC navigation for 8 seconds reproduces the CI failure on the unmodified
test:

DELAYING: http://localhost:3000/workflows/80d9510b-...?_rsc=1d3c8
DELAYING: http://localhost:3000/workflows/80d9510b-...?_rsc=o0tvy
E AssertionError: Locator expected to contain text 'Example Console Workflow'
E Error: element(s) not found
E - waiting for get_by_test_id("wf-name")
1 failed in 31.21s

Same delay, this branch:

1 passed in 30.64s

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 header
takes initialData as SWR fallbackData, so the skeleton never appears while that
request 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 an
immediate 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.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[shahargl]

lgtm

[chiruu12]

Closes#6727.

test_add_workflow asserts on wf-name straight after wait_for_url, but
wait_for_url returns when the URL changes, not when the page has rendered. Until the
RSC navigation for /workflows/{id} comes back, WorkflowDetailHeader has no workflow
and renders a skeleton, and data-testid="wf-name" exists only in the branch after
that. So the locator matches nothing and the failure reads as a text mismatch when the
element is simply absent:

AssertionError: Locator expected to contain text 'Example Console Workflow'
Actual value: <element(s) not found>
- LocatorAssertions.to_contain_text with timeout 5000ms

The 5000ms is page.set_default_timeout(5000) from the browser fixture in
tests/conftest.py:557. On a loaded runner the server render can lose that race, which
is 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:

expect(page.get_by_test_id("wf-name")).to_be_visible(timeout=15000)

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:99
and :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-api and keep-ui images,
down --volumes between runs.

Holding the RSC navigation for 8 seconds reproduces the CI failure on the unmodified
test:

DELAYING: http://localhost:3000/workflows/80d9510b-...?_rsc=1d3c8
DELAYING: http://localhost:3000/workflows/80d9510b-...?_rsc=o0tvy
E AssertionError: Locator expected to contain text 'Example Console Workflow'
E Error: element(s) not found
E - waiting for get_by_test_id("wf-name")
1 failed in 31.21s

Same delay, this branch:

1 passed in 30.64s

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 header
takes initialData as SWR fallbackData, so the skeleton never appears while that
request 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 an
immediate 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.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[shahargl]

lgtm

[chiruu12]

Closes#6727.

test_add_workflow asserts on wf-name straight after wait_for_url, but
wait_for_url returns when the URL changes, not when the page has rendered. Until the
RSC navigation for /workflows/{id} comes back, WorkflowDetailHeader has no workflow
and renders a skeleton, and data-testid="wf-name" exists only in the branch after
that. So the locator matches nothing and the failure reads as a text mismatch when the
element is simply absent:

AssertionError: Locator expected to contain text 'Example Console Workflow'
Actual value: <element(s) not found>
- LocatorAssertions.to_contain_text with timeout 5000ms

The 5000ms is page.set_default_timeout(5000) from the browser fixture in
tests/conftest.py:557. On a loaded runner the server render can lose that race, which
is 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:

expect(page.get_by_test_id("wf-name")).to_be_visible(timeout=15000)

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:99
and :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-api and keep-ui images,
down --volumes between runs.

Holding the RSC navigation for 8 seconds reproduces the CI failure on the unmodified
test:

DELAYING: http://localhost:3000/workflows/80d9510b-...?_rsc=1d3c8
DELAYING: http://localhost:3000/workflows/80d9510b-...?_rsc=o0tvy
E AssertionError: Locator expected to contain text 'Example Console Workflow'
E Error: element(s) not found
E - waiting for get_by_test_id("wf-name")
1 failed in 31.21s

Same delay, this branch:

1 passed in 30.64s

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 header
takes initialData as SWR fallbackData, so the skeleton never appears while that
request 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 an
immediate 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.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[shahargl]

lgtm

[chiruu12]

Closes#6727.

test_add_workflow asserts on wf-name straight after wait_for_url, but
wait_for_url returns when the URL changes, not when the page has rendered. Until the
RSC navigation for /workflows/{id} comes back, WorkflowDetailHeader has no workflow
and renders a skeleton, and data-testid="wf-name" exists only in the branch after
that. So the locator matches nothing and the failure reads as a text mismatch when the
element is simply absent:

AssertionError: Locator expected to contain text 'Example Console Workflow'
Actual value: <element(s) not found>
- LocatorAssertions.to_contain_text with timeout 5000ms

The 5000ms is page.set_default_timeout(5000) from the browser fixture in
tests/conftest.py:557. On a loaded runner the server render can lose that race, which
is 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:

expect(page.get_by_test_id("wf-name")).to_be_visible(timeout=15000)

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:99
and :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-api and keep-ui images,
down --volumes between runs.

Holding the RSC navigation for 8 seconds reproduces the CI failure on the unmodified
test:

DELAYING: http://localhost:3000/workflows/80d9510b-...?_rsc=1d3c8
DELAYING: http://localhost:3000/workflows/80d9510b-...?_rsc=o0tvy
E AssertionError: Locator expected to contain text 'Example Console Workflow'
E Error: element(s) not found
E - waiting for get_by_test_id("wf-name")
1 failed in 31.21s

Same delay, this branch:

1 passed in 30.64s

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 header
takes initialData as SWR fallbackData, so the skeleton never appears while that
request 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 an
immediate 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.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[shahargl]

lgtm

[chiruu12]

Closes#6727.

test_add_workflow asserts on wf-name straight after wait_for_url, but
wait_for_url returns when the URL changes, not when the page has rendered. Until the
RSC navigation for /workflows/{id} comes back, WorkflowDetailHeader has no workflow
and renders a skeleton, and data-testid="wf-name" exists only in the branch after
that. So the locator matches nothing and the failure reads as a text mismatch when the
element is simply absent:

AssertionError: Locator expected to contain text 'Example Console Workflow'
Actual value: <element(s) not found>
- LocatorAssertions.to_contain_text with timeout 5000ms

The 5000ms is page.set_default_timeout(5000) from the browser fixture in
tests/conftest.py:557. On a loaded runner the server render can lose that race, which
is 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:

expect(page.get_by_test_id("wf-name")).to_be_visible(timeout=15000)

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:99
and :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-api and keep-ui images,
down --volumes between runs.

Holding the RSC navigation for 8 seconds reproduces the CI failure on the unmodified
test:

DELAYING: http://localhost:3000/workflows/80d9510b-...?_rsc=1d3c8
DELAYING: http://localhost:3000/workflows/80d9510b-...?_rsc=o0tvy
E AssertionError: Locator expected to contain text 'Example Console Workflow'
E Error: element(s) not found
E - waiting for get_by_test_id("wf-name")
1 failed in 31.21s

Same delay, this branch:

1 passed in 30.64s

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 header
takes initialData as SWR fallbackData, so the skeleton never appears while that
request 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 an
immediate 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.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[shahargl]

lgtm