Preconditions
Inherits public-event-page in page-resolves. Promotion emails and organizer waitlist reports are outside this public branch and noted as reference gaps.
Happy path
Guest clicks Join waitlist.
The waitlist form asks for name and email, using the same public form conventions as registration.
Guest submits.
Server creates one waitlisted registration and returns a tokenized status-check link.
Guest checks status later.
The status page accepts email plus waitlist token and shows either a position or generic “we’ll reach out” copy, depending on event policy.
Failure modes
Capacity full mid-fill
Trigger: a guest starts public registration, loses the race, and is handed into waitlist submit.
The waitlist form is prefilled from registration and completes without requiring the guest to retype. The 409 becomes a waitlist success path.
Two-tab idempotency
Trigger: guest joins waitlist twice in two tabs.
Only one waitlist row exists. The second tab shows the existing waitlist status for that email/token.
Network drop during submit
Trigger: the waitlist POST lands but response is lost.
Retry uses the same Idempotency-Key and returns the original token or status, not a second position.
Invalid input rejected without info leak
Trigger: fake event slug, fake waitlist token, or guessed status URL.
The status page returns the same generic “we couldn’t verify that status link” shape for malformed and unknown inputs.
Source page archived, draft, or deleted
Trigger: waitlist form or status check runs after event lifecycle changes.
The flow shows one generic unavailable page and does not reveal archived, draft, or deleted state.
Browser back after success
Trigger: guest joins waitlist and presses back.
The form does not resubmit. It shows the existing waitlist state with the submitted email read-only.
Open Graph tags present
Trigger: waitlist URL is shared.
OG tags remain canonical to the event hero and URL. Status tokens and email addresses never appear in metadata.
Bot-fill rate-limited
Trigger: one IP submits ten waitlist forms in thirty seconds.
UI surfaces retry-after or captcha. The response does not disclose whether submitted emails are already waitlisted.
Status check wrong email
Trigger: valid token is paired with a different email.
The page uses the same generic verify-failed message as an invalid token. It does not reveal the waitlisted email.
Position hidden by policy
Trigger: organizer disables public position display.
Status page shows “you’re on the waitlist” without a number. The page does not leak total waitlist length in copy or metadata.
Promotion happens while status page is open
Trigger: a confirmed guest cancels and this waitlisted guest is promoted.
Refresh or polling moves to a promoted state with next-step instructions. Email notification channel is referenced but not proven in this public story.
Stable test attributes
Visibility teeth. Each attribute must be effectively visible for its active waitlist state.
| data-test | Where | Purpose |
|---|---|---|
waitlist-panel | Public event page | Root waitlist submission flow |
waitlist-form | Inside panel | Waitlist form |
waitlist-name | Inside form | Name input |
waitlist-email | Inside form | Email input |
waitlist-submit | Inside form | Submit waitlist request |
waitlist-confirmation | Success state | Waitlist confirmation |
waitlist-status-form | Status page | Email plus token lookup |
waitlist-status-email | Status form | Status email input |
waitlist-status-token | Status form | Status token input |
waitlist-position | Status result | Visible waitlist position when policy allows |
waitlist-generic-status | Status result | Generic status when position hidden |
waitlist-promoted | Status result | Promoted from waitlist state |
waitlist-rate-limit | 429 state | Retry-after or captcha message |
waitlist-unavailable | Unavailable state | Generic unavailable page |
waitlist-verify-failed | Status error state | Generic verification failure |
Agent test plan
Run waitlist creation and status lookup against fixtures for visible-position policy, hidden-position policy, wrong-email token pairing, promotion, capacity handoff, and throttling.