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

chore(e2e): surface mokosh-apps SPA bundle hash in timeout diagnostic #122

Merged
YousifShkara merged 1 commit from chore/e2e-capture-spa-build-hash into main 2026-06-06 04:54:39 +02:00
Conversation 0 Commits 1 Files changed 1 +23
YousifShkara commented 2026-06-06 04:54:36 +02:00
Owner
Copy link

When the capture bearer from the SPA login setup times out, the failure output now includes the SPA bundle URLs the browser actually loaded, e.g. https://msp.a8n.systems/assets/mokosh-apps-dxh3ab569d76469a98.js. Each mokosh-apps build emits a content-hashed filename and the deployed asset is served straight off the OCI image, so the hash uniquely identifies which build of mokosh-apps the browser ran against.

The reason for adding it: when a mokosh-apps fix that affects the auth-callback / post-login navigation flow lands on main but staging hasn't redeployed yet, this setup will keep failing in a way that looks identical to a fresh regression. Today the only way to tell "the fix is live" from "still on the old build" is to dig into the trace zip and read the script src out of the HTML. With this change, the bundle hash appears on the first line of the diagnostic alongside the URL trail. Compare the hash to whatever the latest mokosh-apps CI produced for the commit on main; if it doesn't match, the deploy lags, not the code.

Implementation: a small regex matches the bundle filename pattern (mokosh-apps-<hash>.{js,wasm}), the request listener collects matching URLs into a Set for dedup (1-2 entries per run in practice, JS shell + WASM blob), and the catch block dumps them sorted into the error message. No change to the happy path; the regex test runs on every request but is cheap and the listener was already iterating per-request for the Authorization: Bearer check.

When the `capture bearer from the SPA login` setup times out, the failure output now includes the SPA bundle URLs the browser actually loaded, e.g. `https://msp.a8n.systems/assets/mokosh-apps-dxh3ab569d76469a98.js`. Each mokosh-apps build emits a content-hashed filename and the deployed asset is served straight off the OCI image, so the hash uniquely identifies which build of mokosh-apps the browser ran against. The reason for adding it: when a mokosh-apps fix that affects the auth-callback / post-login navigation flow lands on main but staging hasn't redeployed yet, this setup will keep failing in a way that looks identical to a fresh regression. Today the only way to tell "the fix is live" from "still on the old build" is to dig into the trace zip and read the script src out of the HTML. With this change, the bundle hash appears on the first line of the diagnostic alongside the URL trail. Compare the hash to whatever the latest mokosh-apps CI produced for the commit on main; if it doesn't match, the deploy lags, not the code. Implementation: a small regex matches the bundle filename pattern (`mokosh-apps-<hash>.{js,wasm}`), the request listener collects matching URLs into a `Set` for dedup (1-2 entries per run in practice, JS shell + WASM blob), and the catch block dumps them sorted into the error message. No change to the happy path; the regex test runs on every request but is cheap and the listener was already iterating per-request for the `Authorization: Bearer` check.
chore(e2e): surface mokosh-apps SPA bundle hash in timeout diagnostic
Some checks failed
Create release / Create release from merged PR (pull_request) Has been skipped
Details
Check / fmt + clippy + compile + tests (pull_request) Successful in 59s
Details
E2E (staging) / Playwright against staging (pull_request) Failing after 1m38s
Details
cdf46ce5c4 
When the `capture bearer from the SPA login` setup times out, the failure output now includes the SPA bundle URLs the browser actually loaded, e.g. `https://msp.a8n.systems/assets/mokosh-apps-dxh3ab569d76469a98.js`. Each mokosh-apps build emits a content-hashed filename and the deployed asset is served straight off the OCI image, so the hash uniquely identifies which build of mokosh-apps the browser ran against.

The reason for adding it: when a mokosh-apps fix that affects the auth-callback / post-login navigation flow lands on main but staging hasn't redeployed yet, this setup will keep failing in a way that looks identical to a fresh regression. Today the only way to tell "the fix is live" from "still on the old build" is to dig into the trace zip and read the script src out of the HTML. With this change, the bundle hash appears on the first line of the diagnostic alongside the URL trail. Compare the hash to whatever the latest mokosh-apps CI produced for the commit on main; if it doesn't match, the deploy lags, not the code.

Implementation: a small regex matches the bundle filename pattern (`mokosh-apps-<hash>.{js,wasm}`), the request listener collects matching URLs into a `Set` for dedup (1-2 entries per run in practice, JS shell + WASM blob), and the catch block dumps them sorted into the error message. No change to the happy path; the regex test runs on every request but is cheap and the listener was already iterating per-request for the `Authorization: Bearer` check.
YousifShkara deleted branch chore/e2e-capture-spa-build-hash 2026-06-06 04:54:39 +02:00
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
YousifShkara
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!122
No description provided.