Status. Proposed design only. Nothing in this vault is GGA client approval. The GGA client documents are supplied drafts: see GGA-Source-Digest. No application, service or test has been executed; every scenario is Not executed. Delivery fees and dates are open.
Step 07 · Delivery worker, reminders and email
Goal. The worker that delivers committed events, the scheduled jobs and the transactional email.
Blueprint delivery stage: Stage 3 (Delivery-Options-Comparison).
Former 1.3 name: Outbox delivery worker and email. The file name and the step number are kept as stable identifiers (as with the historical DG prefix), so existing links and the step-07 label stay valid.
Not started. This is a specification; no code has been written. The primary-step mapping is an index, not proof that each full scenario can be completed in its step: see Dependency-and-Regression-Table.
Prerequisites
Steps 01, 02, 03, 04, 05, 06 as needed by the table in Dependency-and-Regression-Table; the strict prerequisite is the previous step’s exit evidence. Policy-independent scaffolding may start after the overall start conditions; decision-dependent behaviour and its final oracle stay blocked until the named authority decides. Proposed defaults are recommendations, never prerequisites. Blocked decisions: GL07-staged, GL03-staged, Q07.
Changes (illustrative, not a final schema)
Sources: Blueprint pages cited per item (GGA-Requirement-Register).
Build items:
- Worker with database lock claim; retries after 1 minute, 5 minutes, 30 minutes and 2 hours, then an operations exception queue; no retry of permanent errors (p. 16)
- Reconcile uncertain delivery before resending; recipient and scope re-checked before delivery (pp. 16, 17)
- Profile reminder jobs keyed by company, attestation cycle and reminder type; old-cycle jobs stop after confirmation (pp. 7, 16)
- Listing expiry and refresh, interest and consent follow-up, outcome prompts at 14 and 45 days, renewal invitation (p. 16)
- Transactional email with short authenticated links and no confidential content; provider IDs, delivery outcomes and bounce status (pp. 10, 16)
- A failed notification never bypasses consent, reactivates a listing or marks a contribution paid (p. 16)
Expected outputs and invariants
At-least-once delivery with duplicate protection; exactly-once is never claimed; the core journey does not need any optional channel.
Tests-first subset
Primary scenarios of this step (write these tests first): T11, T34, T35, T36, DG13, DG23, GS13-staged.
Assertions to write first: new GGA scenarios GS13-staged. Legacy scenarios whose primary step is this one: T11, T34, T35, T36, DG13, DG23. Each follows its replacing GS scenario; the 1.3 text is history (Scenario-Dispositions).
Method: make one meaningful test fail for the expected reason, implement the minimum behaviour, refactor without changing the observable contract. A scenario whose decision is still pending stays Blocked by that decision; no oracle is invented.
Deferred integration checks
Scenarios whose primary step is this one but whose full variants need later components:
- T11: needs step 09 (through GS13, GS18).
- T34: needs step 09 (through GS13).
- T35: needs step 09 (through GS13).
- T36: needs step 09 (through GS13).
- DG13: needs step 09 (through GS06, GS24).
- DG23: needs step 09, 10 (through GS13, GS20).
- GS13-staged: needs step 09. Replayed jobs must not duplicate grants (06) or invoices and terms (09).
Follow-up verification brought here
Scenarios (of any step) that can only be completed or rechecked once this step exists:
- GS04-staged: Invitation email delivery needs the worker (07).
- GS06-staged: Reminder jobs and old-cycle stop need the worker (07).
- GS09-staged: Existing-pitch handling (06) and expiry jobs (07).
- GS10-staged: A published listing (04) is needed to pitch against; the owner notification after a new pitch needs the worker (07).
- GS11-staged: Delivery of the contact package needs the worker (07).
Decisions GGA must settle (dependent behaviour stays blocked until the named authority decides)
Exit evidence
Failure injection and replay run on a named build; GS13 is verified in part until invoices and terms exist (09); GS06, GS09 and GS11 are rechecked for their job and delivery parts.
Evidence is recorded only for a named build and fixture. A software scenario is not recorded as Passed until all its relevant variants have been exercised on a named integrated build (step 11).
Navigation: Step-06-Questions-Interest-Discussions-Actions ← this step → Step-08-Daily-Tracking-Views · Implementation-Order-Overview