Aglet

Verify notification retry status and recovery copy

Verification should prove that a person can distinguish an existing event from an unconfirmed channel and knows what to do next. Exercise success and retry paths, inspect timestamps and history, and keep external delivery claims limited to observed confirmation. The final brief should distinguish local confirmation from provider delivery.

Check whether the outcome improved

  1. Check a confirmed path

    Review an event with channel confirmation and ensure status, timestamp, in-app record, action, and destination agree. Record the local event identity so uncertain paths can be compared. Do not treat an absent receipt as proof of failure.

  2. Check a retry path

    Use queued, delayed, or failed state and verify copy states what is known, when it was last attempted, and whether a safe retry or history action exists. Confirm repeated interaction does not duplicate the event.

  3. Review recovery and limits

    Inspect refresh, history, fallback, narrow layout, status announcement, and support or settings path. State tested channels and omitted confirmations. Leave a partial pass when external delivery cannot be directly observed. Compare retry status with the durable in-app record.

What to carry forward

Verification passes when event status, retry state, history, and copy distinguish durable existence from unconfirmed delivery. If a channel or confirmation path is partial, document it. A status of “sent” is not a pass when only local acceptance was observed.

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