Invitation

The Lifecycle

The diagram summarizes the observed transition rows; declared edges without an observed writer remain outside the operational graph.

Transitions Explained

These are interpreted invitation states, combining token presence, timestamps and clock evaluation. Issuing a digest creates a potentially usable link before e-mail delivery is known.

Delivery outcome is separate from invitation usability. Concurrent resends can deliver obsolete links, and the last delivered message need not carry the valid token. Acceptance’s provider call also lies outside the database consumption transaction.

What Cannot Happen

An accepted link is not reopened. Replay for an already active membership returns the earlier success without another activation.

Expiry is checked when the token is used and produces the neutral unusable-token refusal.

Reinstatement cannot revive a withdrawn invitation; a deliberate replacement is needed.

Concurrency and Timing

A unique index admits one outstanding invitation, including an expired row until replacement. Conditional token consumption allows one database acceptance winner. Resend invalidates earlier invitations regardless of which e-mail finishes sending last; validity follows the current invitation and digest, not delivery order. Provider work precedes acceptance’s database transaction and is not atomically protected by token consumption.