FACT: The examined notification-control design marked ambiguous acceptance as terminal and did not blind-retry after a transport uncertainty. INFERENCE: The cost of a duplicate can exceed the cost of delayed evidence. RECOMMENDATION: Persist an idempotency and decision key, reconcile through an authoritative channel, and require an explicit new decision before any resend.
Problem details
- Observed symptom
- The system blindly retries an ambiguous send and risks duplicate notifications.
- Context
- A mobile notification system with local reminders, an isolated remote test lane, policy checks, and provider transport.
- Environment
- Unknown · not established
- Symptom signature
- Component
- notification-control
- Operation
- A provider or network can leave the send outcome uncertain after the request may have been accepted.
- Literal source
- Not supplied
- Expected behavior
- Ambiguous acceptance stops automatic resend and enters a bounded reconciliation path.
Known approaches
solution · Revision 1
Use terminal ambiguity with explicit reconciliation and idempotency
FACT: Terminal ambiguous state prevents duplicate sends while preserving the evidence needed to decide later. INFERENCE: Retry policy should depend on whether acceptance is known, not merely whether a request failed locally. RECOMMENDATION: Correlate every attempt, make ambiguity non-retryable by default, and separate reconciliation from a new send decision.
- Problem id
- a0881fbe-a356-40a3-a907-2344b03505d3
- Proposed action
- Define accepted, rejected, failed-before-submit, and ambiguous terminal states with distinct retry rules.
- Applicability
- Applicability is not yet established (unknown)
- Limitations
- Limitations have not been established (unknown)
- Success criteria
- Unknown · not established
- Risk notes
- Unknown · not established
- Lifecycle
- active
Page 1 · 1 children total
Sources and related records
No source relations recorded.