ENG-5290 viewer URL migration + ENG-5280 & ENG-5371 bug-fix verification
Method: the public viewer surfaces were probed anonymously (status codes, headers, redirects with redirects disabled); the OrgApp / AdminApp GraphQL was used to provision throwaway Displaying sessions (sessionStart / sessionDisplay / sessionShareIssue), open the issued links on the apex viewer, and tear down (sessionEnd). Org: QA (Forms-provisioned).
form.<env>) PASSThe public share viewer moved from the email-flagged live.forms.<env> to the brandable apex form.<env>. 19 of 22 checks passed, 0 failed; the 3 remaining are a test-harness limitation, not a defect (explained below).
| Check | Result | Evidence |
|---|---|---|
| Viewer served on apex over valid TLS + HSTS | PASS | Let's Encrypt cert CN=form.dev.sense.engineering; strict-transport-security present |
Legacy live.forms.dev fully retired | PASS | root and /{token} both 404, no redirect/alias |
| Bare apex → product home | PASS | form.dev/ → 302 → forms.dev/, query preserved, token paths untouched, GET-only |
OrgApp share link targets form.dev and renders | PASS | issued link form.dev/<token> opened end-to-end (see screenshot) |
| OrgApp reveal-modal UI capture (3 steps) | BLOCKED | test-harness only — see note |
form.dev.sense.engineering renders the form end-to-end.Those 3 steps only capture the OrgApp "Share link" pop-up in the UI. Reaching it requires navigating to /sessions/<relayId>/shares, and the QA org's session id contains a + that Angular's router corrupts in a hand-built URL, so the screen shows "Session not found". That blocks the click-through, but it is not a product defect (real users reach that screen by clicking in-app, and the share links they open are url-safe tokens). The outcome those steps would confirm was verified another way: the OrgApp's own backend issued a form.dev link, it rendered, and the host mapping is covered by the viewer-url.spec.ts unit test. Hence 0 failures.
Root cause was an ampersand (&) in a <choice> text corrupting the choice wire-format (the encoder prefixes the selected option with & and joins with |). Reproduced the reported form on the viewer:
| Group | Options rendered | Result |
|---|---|---|
| radio "Duration" | "Less than a day", "A whole day", "More than a day" (3/3) | PASS |
| check "Pick options" | "First", "Second", "& Third" (3/3) | PASS |
All options render, including the ampersand choice, with correct selected states. Nothing missing or truncated.
& Third.Issued 4 fresh share links and polled each token URL immediately (every 500ms, redirects disabled), then opened one in the browser immediately:
| Trial | First-request status | Sequence |
|---|---|---|
| 1 | 302 | 302 → 200 |
| 2 | 302 | 302 → 200 |
| 3 | 302 | 302 → 200 |
| 4 | 302 | 302 → 200 |
| Browser (immediate) | — | SPA loaded then rendered the form |
Every first open returned 302 (the normal share-token cookie-mint redirect) then 200, never a 404. One isolated 404 seen earlier looked like a cold-start blip and did not recur; recommend a quick prod sanity check after deploy.