Event-processing case cards
Paste JSON into the local inbox simulator. Use View stored events before and after each attempt. These are fabricated payloads; neither email nor credentials are needed.
Healthy baseline
{"messageId":"healthy-01","consent":true,"confidence":0.95}
Pick one failure/recovery sequence
| Card | First attempt | Recovery / repeat |
|---|---|---|
| Duplicate delivery | {"messageId":"duplicate-01","consent":true,"confidence":0.95} |
Submit identical JSON again; compare event count and queued flags |
| Expired authorization | {"messageId":"auth-01","consent":true,"confidence":0.95,"oauth":"expired"} |
Remove oauth and retry the same ID; this simulates resolved authorization, not a real login |
| Malformed attachment | {"messageId":"attachment-01","consent":true,"confidence":0.95,"attachment":"malformed"} |
Remove attachment and retry the same ID to simulate a corrected payload |
| Opt-out | {"messageId":"optout-01","consent":false,"confidence":0.95} |
Redeliver unchanged; consent must stay false—do not fabricate opt-in to make a send succeed |
| Low confidence | {"messageId":"review-01","consent":true,"confidence":0.5} |
Redeliver unchanged; it should remain in review. Human review resolution is not implemented |
| Delayed redelivery | {"messageId":"delay-01","consent":true,"confidence":0.95} |
Perform another UI action, then resubmit unchanged; only redelivery semantics are tested, not real delay handling |
Use a unique message ID for each card. Correct rejected payloads may be retried using the same ID because no event was saved. Accepted low-confidence or opted-out events are not edited by resubmitting different fields; changed-consent and review-resolution workflows are out of scope.
Record actual status, stored count, state and queued decision against R4–R6. For a rejected attachment, state:review in an error response is not proof that a review item was stored. Explain that limitation.