The two consent-modal event tests have never passed: the wizard's Next click is intercepted by .blast-form

[rubenvdlinde]

What

tests/e2e/event-wiring.spec.ts:396 and :419 have failed on every run since they were added, and both fail the same way: a click on the wizard's Next button is intercepted, and openConsentModal() retries it until the 120s test timeout.

Error: locator.click: Test timeout of 120000ms exceeded.
Call log:
  - waiting for locator('button').filter({ hasText: /^Next$/ }).first()
    - locator resolved to <button type="button" class="button-vue button-vue--primary">…
  - attempting click action
    - element is visible, enabled and stable
    - performing click action
    - <div schema="blast" class="blast-form" register="pipelinq">…</div> intercepts pointer events
  - retrying click action

Provenance

Both tests, and the openConsentModal() helper they share, were added by bb8788a (#1693, "repair the consent notification, and cover three more event chains"). The run immediately before that commit shows neither test in its failure list, because neither existed yet. They have never been green.

Why it reads as a timeout and is not one

The button is visible, enabled and stable, so Playwright does not fail on the overlay. It keeps retrying the click, and the only thing that ever ends it is the test budget. That is why the error names a timeout and says nothing about the interception unless you read the call log.

The interceptor is div.blast-form itself, so this is a layering or step-transition problem in the wizard rather than a slow page. Raising the timeout would not help.

Adjacent, and probably related

openConsentModal() advances the wizard with an unbounded loop:

while (await next.isVisible().catch(() => false)) {
  await next.click()
}

If a click stops advancing the wizard, that loop cannot terminate on its own. Even once the interception is fixed, this is worth bounding with a step-count assertion so the failure is fast and names the step it stuck on.

Not the routing change

Ruled out: #1684 (createWebHistory) was already merged in the run where these tests did not appear, and the other five failures in the same run were all resolved by #1706, #1711 and #1713 without touching this one.

[github-actions]

Thank you for opening this issue! It has been assigned to @rubenvdlinde for review.

What happens next:

1. A maintainer will review this issue and determine the appropriate action
2. If accepted, it may be converted into an OpenSpec change for structured development
3. You will be notified of any status changes

Triage labels:

• triage:accept-feature — accepted as a new feature
• triage:accept-bugfix — accepted as a bug fix
• triage:needs-info — more information needed
• triage:wontfix — will not be addressed
• triage:duplicate — duplicate of another issue

[rubenvdlinde]

Superseded by #1707, which was already open when I filed this and diagnoses it further than I did.

I had the interception (div.blast-form swallowing the Next click) and the unbounded while (next.isVisible()) next.click() loop. #1707 has both, plus two causes I did not find:

• The two tests interleave. They drive the same six-step wizard against the same instance and both end by POSTing a blast, so "Create blast" comes up disabled in whichever loses. fix(e2e): de-hash the portal accessibility spec, and stop the consent wizard hanging #1707 measured 1 failed / 1 passed on one run and 2 passed on the next, with each passing alone twice, and puts the describe block in mode: 'serial'.
• selectedChannel is initialised to the string 'email' while the NcSelect options are {value,label} objects, so opening and dismissing that control clears the model and disables submit permanently.

Closing in favour of that PR. Leaving this comment rather than deleting the issue, because the fingerprint in the description is the one a future reader will search for: a 120s timeout whose message names neither the interception nor the loop.