Test run d3ef9303

Abuse limits hold

release-critical

partly run

Mailbombing one address and brute-forcing a PIN are both blocked, and one abuser cannot lock anybody else out.

12 passed · 6 not run · 1m 11s of browser time · auth/rate-limiting.spec.ts

·· one social identity cannot spray many addresses 1.6s

Not run — Simulator disabled. Start the dev server with ALLOW_DEV_AUTH_SIMULATION=true.

✓✓ sign-in links per address allows the limit, then blocks 2.0s

✓✓ sign-in links per address a different address is unaffected 2.6s

✓✓ sign-in links per IP allows the limit across distinct addresses, then blocks 10.0s

✓✓ sign-in links per IP a different IP is unaffected 10.7s

·· sign-in links per IP an unknown client IP gets no shared bucket 4.7s

Not run — Cloudflare always sets CF-Connecting-IP, so no caller here is unattributable — asserted in tests/unit/server/rate-limit.spec.ts

✓✓ PIN sign-in blocks after the failure limit 3.5s

✓✓ PIN sign-in a different IP is unaffected 4.1s

·· PIN sign-in an unknown client IP gets no shared bucket 3.1s

Not run — Cloudflare always sets CF-Connecting-IP, so no caller here is unattributable — asserted in tests/unit/server/rate-limit.spec.ts

Confirming a missing email

release-critical

not run

When a provider returns no address, the visitor is asked for one and no account is created until they give it.

34 not run · 14.4s of browser time · auth/email-confirmation.spec.ts

Nothing here ran — Simulator disabled. Start the dev server with ALLOW_DEV_AUTH_SIMULATION=true.

17 scenarios waiting on this

·· claiming an existing account does not sign the requester in 0.3s

·· the form names the provider that failed to supply an address 1.3s

·· the form the NAME step prefills whatever the provider did supply 0.9s

·· the form requires an email address 0.4s

·· the form blocks an address the browser itself rejects 1.1s

·· the form rejects an address that passes the browser but fails our rule 0.8s

·· the form asks for nothing but the address 0.4s

·· on submit confirms the address it sent to 1.1s

·· on submit still does not sign the user in 0.6s

·· on submit links no provider identity until the address is proven 0.4s

·· on submit a mistyped address is recoverable 0.4s

·· after the emailed link is opened a blank-name account is asked for a name, exactly once 0.3s

·· after the emailed link is opened an account that already has a name keeps its own 0.4s

·· after the emailed link is opened the social identity is linked only now 0.4s

·· without a live pending identity opening the confirm page directly bounces to sign-in 0.4s

·· without a live pending identity shows an explanation that names no provider 0.4s

·· without a live pending identity a cleared pending cookie bounces mid-flow 0.3s

Deep links survive sign-in

release-critical

partly run

Someone sent to sign in from a booking or ticket link lands back where they were going.

6 passed · 10 not run · 1m 19s of browser time · auth/deep-link-redirect.spec.ts

10 of these scenarios did not run — Simulator disabled. Start the dev server with ALLOW_DEV_AUTH_SIMULATION=true.

✓✓ sign-in page carries the redirect through to the provider links 29.9s

✓✓ sign-in page preserves a path that carries its own query string 9.2s

✓✓ sign-in page defaults to the tenant root when no redirect was given 6.6s

·· after signing in returns the user to a plain deep link 2.6s

·· after signing in returns the user to a deep link with its state intact 2.1s

·· after signing in returns to the tenant root when no redirect was requested 1.3s

·· rejects off-site redirects sends the user to the tenant root instead of //evil.example.com 1.1s

·· rejects off-site redirects sends the user to the tenant root instead of https://evil.example.com 0.6s

Existing customers keep their account

release-critical

not run

An account created before the identity model still resolves to the same record on its first sign-in after a deploy, with its saved cards and bookings intact.

14 not run · 0.1s of browser time · auth/legacy-account-continuity.spec.ts

Nothing here ran — MONGO_URI unavailable

7 scenarios waiting on this

·· a legacy social user keeps their id, cards and bookings 0.0s

·· the provider identity is adopted, so the next sign-in matches at step 1 0.0s

·· a stored address in different casing still resolves to the same account 0.0s

·· a legacy email-OTP user is found, not duplicated 0.0s

·· a legacy blank-name account is prompted once, then keeps its id 0.0s

·· a name the user set is not reverted by signing in 0.0s

·· legacy workspace roles survive the sign-in 0.0s

Social sign-in

release-critical

passed

Google, Facebook and Microsoft buttons are present and hand off to the right provider.

26 passed · 3m 38s of browser time · auth/oauth-providers.spec.ts

✓✓ signin page provider buttons all provider buttons are visible and link to correct auth paths 5.3s

✓✓ signin page provider buttons provider links carry the default redirect 6.2s

✓✓ signin page provider buttons provider links carry the requested redirect 5.9s

✓✓ signin page provider buttons provider links do not leak an origin parameter to the browser 9.2s

✓✓ signin page provider buttons provider text labels are visible on desktop, hidden on mobile 5.1s

✓✓ OAuth redirect flow clicking Google button redirects to accounts.google.com 9.0s

✓✓ OAuth redirect flow clicking Facebook button redirects to facebook.com 9.8s

✓✓ OAuth redirect flow clicking Microsoft button redirects to login.microsoftonline.com 7.7s

✓✓ error handling UI oauth_cancelled displays cancellation alert 5.4s

✓✓ error handling UI oauth_invalid displays failure alert 6.4s

✓✓ error handling UI oauth_error displays error alert 5.6s

✓✓ error handling UI token_expired displays expiry alert 6.2s

✓✓ error handling UI token_invalid displays invalid link alert 8.6s

The site loads

release-critical

passed

A first-time visitor reaches the tenant home page and the sign-in page, and both render.

4 passed · 30.4s of browser time · ui/page-loading.spec.ts

✓✓ should load the homepage correctly 9.3s

✓✓ should navigate to signin page 8.6s

What it looked like

Who the account belongs to

release-critical

not run

Sign-in resolves by provider subject id first and verified email second — never by email alone. This is the invariant behind the saved-card incident.

34 not run · 10.9s of browser time · auth/identity-resolution.spec.ts

Nothing here ran — Simulator disabled. Start the dev server with ALLOW_DEV_AUTH_SIMULATION=true.

17 scenarios waiting on this

·· two different people without emails stay separate accounts 0.4s

·· the profile page lists the social accounts that can sign in as you 0.4s

·· the simulator refuses a non-allowlisted forwarded host 0.4s

·· provider returns no email microsoft without an email lands on the confirmation form 0.4s

·· provider returns no email facebook without an email lands on the confirmation form 0.3s

·· provider returns no email google without an email lands on the confirmation form 0.4s

·· provider returns no email creates NO user document — nothing is written before an address is proven 0.4s

·· provider returns no email does not establish a session 0.4s

·· provider returns no email the pending cookie is httpOnly and host-wide 0.4s

·· provider returns an email signs straight in without a confirmation step 0.4s

·· provider returns an email attaches the provider identity to the account 0.4s

·· provider returns an email a returning identity resolves to the same account 0.4s

·· name handling a provider that sent no names cannot sign in nameless 0.4s

·· name handling a first name with no last name is still incomplete 0.4s

·· name handling supplying the missing name completes the sign-in without an OTP 0.4s

·· name handling the name form requires both parts 0.3s

·· name handling seeds a blank name, then never overwrites it 0.4s

Switching language

passed

Choosing a language changes the rendered text and the choice survives navigation.

12 passed · 2m 23s of browser time · i18n/locale-switching.spec.ts

✓✓ should navigate to settings/language page 12.0s

✓✓ should switch from English to Greek and verify locale change 14.1s

✓✓ should switch from English to French and verify locale change 13.5s

✓✓ should switch from English to Spanish and verify locale change 13.1s

✓✓ should persist locale choice across page navigation 18.2s

✓✓ should handle invalid locale gracefully 9.3s

What it looked like

Nothing failed — but the critical journeys did not all run

98 scenarios did not run

Journeys

Abuse limits hold

Confirming a missing email

Deep links survive sign-in

Existing customers keep their account

Social sign-in

The site loads

What it looked like

Who the account belongs to

Switching language

What it looked like