journey-runner.js has no browser-Back action and no 5xx check: a Mendix page that fails its data sources after Back still passes its landing guard (patch offered: { "do": "back" } and "ui": { "no5xx": true }) #564

File: project-tests/e2e/journey-runner.js lines 162-172 (describeAct), 174-319 (act, default: throw new Error('unknown action …') at 319), ~740-830 (runJourney step loop: actions, then the ui.ready landing guard at 812-823) · Toolkit: 92331e4 (origin/master, 23 Oct) · mxcli: v0.27.0 · Mendix: 11.14.0

Summary

Two gaps, found together on one defect:

1. No browser Back. The runner's actions are nav, click, fill, combobox, dismissModal, wait. There is
   no way to press the browser's Back button. Back is a path no in-app click exercises: the Mendix client rebuilds
   the previous page from its own history and re-sends the client state it kept. Defects that live only there (a
   new, unsaved object in the client state that the role may not create, for example) cannot be expressed as a
   journey, so they can only be found by the monkey's random backAfterSubmit and cannot be pinned by a journey or
   a named control after the fix.
2. No 5xx check. When a page's data sources fail (HTTP 560 on /xas/), Mendix can still render the page frame:
   the layout, the headings and the grid container are there, the rows are not. The ui.ready landing guard sees
   its selector and records PASS. Only the monkey's oracle looks at HTTP status, so a journey walk reads green over a
   page whose every server call failed.

Local patch (about 36 lines, one commit, in use since 23 Oct)

a. { "do": "back" } in act() (and a describeAct line, verb "Browser Back"):

case 'back': {
  await page.goBack({ waitUntil: 'networkidle', timeout: a.timeout || 15000 }).catch(e => {
    if (!/timeout/i.test(e.message)) throw e;
    console.log(`    WARN back: networkidle not reached in ${a.timeout || 15000} ms; settling as usual`);
  });
  const url = page.url();
  const base = String(cfg.baseUrl).replace(/\/+$/, '');
  if (!url || (url !== base && !url.startsWith(base + '/')) || /\/login\.html(?:[?#]|$)/.test(url))
    throw new Error(`Back left the app (now at ${url}): the previous action pushed no history entry`);
  break;
}

A networkidle timeout alone is not a failure (a polling page never goes idle; the history move has happened). Back
leaving the app is a failure, because every later check would measure the login page or another site. The same
"left the app" test is monkey.js's leftApp().

b. Opt-in "ui": { "no5xx": true } on a step: a page.on('response') listener collects every answer >= 500
from the step's first action until its landing guard, and the step gets one more row:

<step>: no HTTP 5xx during the step    PASS
<step>: no HTTP 5xx during the step    FAIL   2 answer(s) >= 500: 560 POST <base>/xas/; 560 POST <base>/xas/

The row is recorded before the not-reached bail-out, so when a 5xx is why the page never landed, the walk shows
the cause next to the landing FAIL. The listener is removed on every exit path (the step's seal() finaliser).
Opt-in, so no existing journey changes result.

Evidence it works

A Back journey written for the defect (click an action that starts a background job, press Back, land on the page
again, no5xx: true) went 60 PASS / 2 FAIL on the defective build (both FAILs the no5xx rows, 560 on /xas/;
the landing guard PASSED on the same steps) and 62 / 62 PASS after the fix. A named control for it was PROVEN.

Suggested fix

1. Port back and ui.no5xx (or take the patch as a PR).
2. Consider making no5xx the default for every step, with "no5xx": false to opt out. A 5xx during a user step is
   almost never intended; the opt-in was chosen locally only to keep existing results stable.
3. Add both to --positive-control: a mutant that sets ui.no5xx on a step whose action is pointed at a request
   that 500s (or that asserts no5xx after an action known to fail), so the check has been seen going red.
4. examples/validate-journeys.js: add back to ACTIONS and accept ui.no5xx as a boolean (comment on validate-journeys.js rejects the runner's offline/online verbs and does not check the notMeasurableWhen step tag #522).
5. Document both in skills/journey-proof.md (the action table and the ui rung).
6. Self-test: a fixture page that answers 560 on load must give reached PASS and no HTTP 5xx FAIL; back after an
   action that pushed no history must throw "Back left the app".

How to retest

A journey: open a page, click a button, { "do": "back" }, land on the page again with ui: { ready, no5xx: true }.
On a page with a client-state defect after Back: the no5xx row FAILs while reached PASSes. On a clean page: all PASS.