Batch cardinality

Two posts arrived together. Why were there four task activations?

Group rows by your supplied observation time, count distinct non-summary identities and make summary overhead or repeated identity rows visible. Same-time children remain distinct when their identity tuples differ.

Quick answer

Four activations do not necessarily mean four child notifications

A same-time callback batch can contain several distinct child notifications, a group-summary row and a repeated identity. This worksheet groups rows only when their supplied observed time is exactly equal, then reports those categories separately. It does not invent a debounce window or merge different identities merely because they arrived together.

The included example has four callback rows in one observed batch: two distinct children, one repeated child identity and one explicit group summary. The result is two distinct child identities, one summary row and one replay-surplus row. Replace the aliases and times with a redacted capture from your own harmless diagnostic task.

Browser-local worksheet

Reconcile callbacks within each supplied batch

Rows sharing an observed time are compared as one supplied batch. The result counts; it does not invent a debounce duration or recommend deleting an activation.

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.

Distinct child identitiesCounts unique package, ID, tag and user tuples among non-summary rows.

Summary overheadReports rows explicitly marked as group summaries separately.

Replay surplusCounts repeated strong child identities inside the same supplied observation batch.

Why batch counts can disagree with the status bar

The status bar is a current visual state, while an event listener observes lifecycle activity. An application may post multiple child notifications and a group summary close together. A record may also be updated while retaining part of its identity. AutoNotification or Tasker settings can expose the rows differently. Counting only visible cards after the fact therefore cannot reconstruct which callbacks ran.

Use the supplied observation time from one logging method consistently. If your capture rounds time values, unrelated callbacks may appear simultaneous; choose a precision that your source actually provides and state it in your notes. Do not create artificial time windows until the exact-timestamp result has been inspected.

Interpret the three batch components

Distinct childrenUnique package, notification ID, tag and user tuples among rows not marked as summaries.

Summary overheadRows explicitly marked as group summaries; they stay visible instead of being folded into a child count.

Replay surplusAdditional occurrences of the same strong child identity inside the exact supplied batch.

A replay surplus is a diagnostic observation, not permission to ignore the row. Two callbacks with the same aliases can still differ in content that this privacy-preserving worksheet intentionally does not collect. Confirm behavior with a reversible log and the current listener documentation before changing an automation.

Move from a count to the next check

If summary overhead explains the difference, inspect the listener’s current group-summary option. If replay surplus remains, use the timeline replay trace to compare post times and sequence. If one weak notification ID appears to represent several records, use the identity collision worksheet. Keep the callback-versus-snapshot worksheet separate because an active query is a set, not a new callback stream.