Callback lifecycle trace

One visible notification. Which callback actually ran?

Turn short anonymized identity rows into a temporal trace. Separate a first callback, group summary, possible active-record replay and possible update without connecting to Android or executing a Tasker action.

Diagnostic boundary: this worksheet never reads or suppresses notifications. Matching IDs, timestamps or text are not treated as sufficient proof by themselves.

Quick answer

A visible notification and a Tasker activation are different observations

Tasker can receive another notification event even when Android appears to show the same visible record. The current Tasker documentation notes that a duplicate already present in the status bar can still trigger the event unless New Only is selected. Group summaries, updates and plug-in query snapshots can add other rows that look similar without representing the same lifecycle step.

Replay Trace does not choose a suppression rule. It compares only anonymized identifiers and times that you supply. In the included example, the first child identity is classified as new, the explicitly marked summary stays separate, the same strong identity and post time becomes a possible replay, and the later post time becomes a possible update. Those labels narrow the next inspection; they do not prove an Android or Tasker defect.

Browser-local worksheet

Classify the callback sequence

Use the order observed in your own redacted log. A repeated strong identity with the same supplied post time is labeled POSSIBLE_REPLAY; it is not declared a universal root cause.

Aliases only · no device access

Ten comma-separated columns: sequence, origin (callback/snapshot), package alias, notification ID, tag alias, user alias, group key, summary flag, optional post time, observed time. Use short aliases—never paste notification text, names, phone numbers or account data.

No diagnosis yet

The worksheet does not connect to Android, Tasker or AutoNotification. It classifies only the identity rows shown above.

Four different questions, four different results

Simultaneous batchCompare observed callback count, distinct child identities, summary overhead and replay surplus. Open batch view.

Active snapshotSeparate the callback set from records already present in a supplied active snapshot. Open set view.

Identity collisionSee when package + notification ID collapses distinct tag or user tuples. Inspect identity fields.

Build a redacted callback trace

Capture the order in which your own reversible diagnostic task observed callbacks. Replace the application package, tag, user and group values with consistent short aliases. Keep the notification ID, summary flag, post time and observed time only when your listener actually exposes them. Do not paste message text, sender names, phone numbers, account identifiers, tokens or exported Tasker configuration.

Use one row per observed callback. Sequence expresses observation order; it is not an Android timestamp. Post time belongs to the notification record when available, while observed time belongs to your diagnostic capture. Leaving a missing value blank is safer than inventing one: the worksheet returns an ambiguity when the fields are insufficient for the comparison.

Read the classifications as evidence limits

NEW_CALLBACKThe strong identity tuple has not appeared earlier in the supplied callback sequence.

GROUP_SUMMARYThe row is explicitly marked as a summary and is not silently counted as a child notification.

POSSIBLE_REPLAYThe same supplied identity and comparable post time appeared earlier. “Possible” is deliberate.

POSSIBLE_UPDATEThe identity repeats with a changed supplied post time, which is compatible with an updated record.

AMBIGUOUS_IDENTITY_REUSEThe tuple repeats but a field required for the bounded comparison is missing.

No automatic suppressionThe worksheet never decides that a callback is safe to ignore or an action is safe to skip.

Verify before changing a Tasker profile

Reproduce with a harmless logging action first. Compare the event profile settings, the listener or AutoNotification version, group-summary behavior and the difference between an incoming event and a later active-notification query. Change one condition at a time and retain a rollback copy. If the trace changes after enabling a filter, verify that legitimate updated or child notifications are still handled before using the same rule in an action with side effects.

See the method and limitations for the exact deterministic rules and the privacy boundary before entering rows.