Aglet

Investigate notification channel fallback across delivery states

An investigation should explain what happens when the preferred channel is muted, denied, delayed, or unavailable. Replay event paths, compare durable in-app state with alternate delivery, and inspect duplicate prevention. Keep event identity and user choice at the center of the trace.

Build a useful investigation brief

  1. Build the channel matrix

    List event, identity, preference, channel, attempt, status, fallback, in-app record, notification copy, and user action for success and failure paths. Include an event that should not escalate. Record platform permission as an external condition.

  2. Trace one failure

    Change preference or channel state and compare in-app history, alternate channel, timing, copy, and duplicate output. Check whether fallback preserves the same event and destination. Record a muted path so “disabled” is not treated as transport failure.

  3. Write the fallback brief

    State first delivery boundary, affected event classes, user preference, and competing explanations. Recommend one bounded fallback or durable-status experiment with a pass condition. Do not claim an alternate channel delivered when only an event record exists.

What to carry forward

The investigation is complete when preferred, failed, muted, and fallback paths have reproducible boundaries, or the first unknown is explicit. Stop with one bounded experiment. Keep durable event visibility separate from channel confirmation in the brief.

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