Aglet

Investigate notification retry visibility from event to channel

An investigation should show what a person can know while an event is queued or retried. Replay successful, delayed, and failed paths, compare local record with channel confirmation, and inspect recovery copy. Keep internal attempt detail out of the user promise unless it helps a decision.

Build a useful investigation brief

  1. Build the status matrix

    List event ID, creation time, local state, channel, attempt, retry, confirmation, in-app record, copy, action, and timestamp for representative paths. Include a state where delivery cannot be confirmed and one success control.

  2. Trace the uncertain path

    Follow a queued or failed event through retry and user refresh. Compare status, history, action, and duplicate behavior. Record whether the user can tell the event exists even when a channel has not confirmed it.

  3. Write the visibility brief

    State first uncertainty boundary, affected channels, and competing explanations such as stale status, missing history, or actual event failure. Recommend one bounded status or recovery experiment with pass criteria. Do not call a retry delivered without confirmation.

What to carry forward

The investigation is complete when event and channel states, retry boundary, and user-visible copy are reproducible, or the first unknown is explicit. Stop with one bounded status experiment. Keep local durable evidence separate from external delivery confirmation.

Technical background: Android developer documentation.

Keep the decision with the work.

Use a Work Item in Aglet to record the problem, the evidence you have, and the next decision. Add an owner and priority, then keep updates in the discussion so the next person can follow the reasoning.

Create an account See the product workflow