psa-systems/mokosh-server
Watch
9
0
Fork
You've already forked mokosh-server
 1
Code Issues Pull requests Projects Releases 10 Packages Wiki Activity Actions

fix(e2e): recover chromium SPA login from credential-form re-render race #408

Closed
Claude-Run wants to merge 0 commits from fix/PMS-592-chromium-spa-login-credential-race into main
pull from: fix/PMS-592-chromium-spa-login-credential-race
merge into: psa-systems:main
Conversation 0 Commits - Files changed 237 +75 -21
Claude-Run commented 2026-06-30 16:04:11 +02:00
Member
Copy link

The chromium form-validation run on PR #407 (run 2871) timed out with the SPA login stuck on a bare /login, never reaching /login/2fa, while setup (same loginViaSpa, same Desktop Chrome, 2s earlier), firefox, and webkit all logged in fine. The captured URL trail ends with a full frame navigation back to a bare /login (the ?redirect=...&checked=1 query dropped), which is the bunyip hub rejecting a credential POST and 302'ing to a fresh form: the server-rendered hub form re-rendered between fill and click, the click POSTed an empty form, and the helper then polled a never-submitted form until the 30s timeout. chromium lost that race; the other engines won it.

Harden the credential step: verify the typed email/password values survived right before clicking, and confirm the password field leaves the DOM after submit (the hub advancing to 2FA / onward). If either check fails, the form was re-rendered out from under us, so re-fill the freshly-rendered form and submit again (up to 3 attempts) instead of charging ahead with an empty POST. firefox/webkit/setup, which already win the race, take the same fast path with no behavior change.

#PMS-592

The chromium form-validation run on PR #407 (run 2871) timed out with the SPA login stuck on a bare `/login`, never reaching `/login/2fa`, while `setup` (same loginViaSpa, same Desktop Chrome, 2s earlier), firefox, and webkit all logged in fine. The captured URL trail ends with a full frame navigation back to a bare `/login` (the `?redirect=...&checked=1` query dropped), which is the bunyip hub rejecting a credential POST and 302'ing to a fresh form: the server-rendered hub form re-rendered between `fill` and `click`, the click POSTed an empty form, and the helper then polled a never-submitted form until the 30s timeout. chromium lost that race; the other engines won it. Harden the credential step: verify the typed email/password values survived right before clicking, and confirm the password field leaves the DOM after submit (the hub advancing to 2FA / onward). If either check fails, the form was re-rendered out from under us, so re-fill the freshly-rendered form and submit again (up to 3 attempts) instead of charging ahead with an empty POST. firefox/webkit/setup, which already win the race, take the same fast path with no behavior change. #PMS-592
fix(e2e): recover chromium SPA login from credential-form re-render race
Some checks failed
Check / fmt + clippy + build + tests (pull_request) Failing after 4s
Details
Integration / integration tests (pull_request) Failing after 7s
Details
E2E / Playwright against staging (pull_request) Failing after 1m16s
Details
Create release / Gate (release-branch merges only) (pull_request) Successful in 0s
Details
Create release / Create release from merged PR (pull_request) Has been skipped
Details
026120bb9b 
The chromium form-validation run on PR #407 (run 2871) timed out with the SPA login stuck on a bare `/login`, never reaching `/login/2fa`, while `setup` (same loginViaSpa, same Desktop Chrome, 2s earlier), firefox, and webkit all logged in fine. The captured URL trail ends with a full frame navigation back to a bare `/login` (the `?redirect=...&checked=1` query dropped), which is the bunyip hub rejecting a credential POST and 302'ing to a fresh form: the server-rendered hub form re-rendered between `fill` and `click`, the click POSTed an empty form, and the helper then polled a never-submitted form until the 30s timeout. chromium lost that race; the other engines won it.

Harden the credential step: verify the typed email/password values survived right before clicking, and confirm the password field leaves the DOM after submit (the hub advancing to 2FA / onward). If either check fails, the form was re-rendered out from under us, so re-fill the freshly-rendered form and submit again (up to 3 attempts) instead of charging ahead with an empty POST. firefox/webkit/setup, which already win the race, take the same fast path with no behavior change.

#PMS-592
nrupard closed this pull request 2026-06-30 16:06:52 +02:00
Some checks failed
Check / fmt + clippy + build + tests (pull_request) Failing after 4s
Required
Details
Integration / integration tests (pull_request) Failing after 7s
Details
E2E / Playwright against staging (pull_request) Failing after 1m16s
Required
Details
Create release / Gate (release-branch merges only) (pull_request) Successful in 0s
Details
Create release / Create release from merged PR (pull_request) Has been skipped
Details

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
psa-systems/mokosh-server!408
No description provided.