← All Reports

Sense Forms — DEV Regression

ENG-5290 viewer URL migration  +  ENG-5280 & ENG-5371 bug-fix verification

📅 2026-06-17 🌐 form.dev / our.forms.dev / admin.forms.dev 🤖 Claude Opus 4.8 + playwright-cli 👤 Paul Wagner
PASS
Overall
3
Tickets verified
0
Failures
DEV
Environment

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).

ENG-5290 — ViewerApp apex domain (form.<env>) PASS

The 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).

CheckResultEvidence
Viewer served on apex over valid TLS + HSTSPASSLet's Encrypt cert CN=form.dev.sense.engineering; strict-transport-security present
Legacy live.forms.dev fully retiredPASSroot and /{token} both 404, no redirect/alias
Bare apex → product homePASSform.dev/302forms.dev/, query preserved, token paths untouched, GET-only
OrgApp share link targets form.dev and rendersPASSissued link form.dev/<token> opened end-to-end (see screenshot)
OrgApp reveal-modal UI capture (3 steps)BLOCKEDtest-harness only — see note
Issued share rendering on form.dev
An OrgApp-issued share opened on form.dev.sense.engineering renders the form end-to-end.

Why 3 steps are "blocked", not "fail"

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.

ENG-5280 — Radio & check not showing all options FIXED

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:

GroupOptions renderedResult
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.

Radio and check groups showing all options including '& Third'
Both groups display every option, including & Third.

ENG-5371 — 404 when first opening forms link NOT REPRODUCED

Issued 4 fresh share links and polled each token URL immediately (every 500ms, redirects disabled), then opened one in the browser immediately:

TrialFirst-request statusSequence
1302302 → 200
2302302 → 200
3302302 → 200
4302302 → 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.

Freshly issued link rendering on first open, no 404
A freshly-issued link renders on first open — no 404.
Verdict: ENG-5290 verified (zero failures); ENG-5280 fixed; ENG-5371 not reproducible. Companion markdown reports and the test-case CSVs accompany this report.