Aglet

Triage duplicate notification updates before coalescing

Repeated notifications may represent one event retried or several legitimate changes. Triage identity and outcome before grouping or replacing messages. Compare event key, resource, state, timestamp, channel, and action so a duplicate representation does not hide a real second update.

Establish what is happening

  1. Capture the event stream

    Record event identity, resource, state, timestamp, retry marker, channel, notification ID, and action for each message. Include a repeated save, a worker retry, and two real state changes. Keep in-app history beside external delivery.

  2. Compare meaningful change

    Ask whether the second message changes state, context, or available action. Compare identical payloads with a newer version and a repeated delivery. A changed timestamp alone does not make a message meaningful if the event identity remains the same.

  3. Set a coalescing boundary

    State when to update, group, retain, or suppress a message and what history remains. Preserve an example that must stay separate. Stop when another reviewer can distinguish retry from legitimate repeat without trusting arrival order alone.

What to carry forward

The triage output is a coalescing boundary with event identity, state change, channel, and retained history. Stop when duplicate representation and real repeated work are distinguishable. If identity is missing, keep messages visible and route the provenance question.

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