Skip to content

Data Diff Anomaly Reporting

How the Data Diff check reports differences: the anomaly message it produces, what the counts mean, how the differing rows are rendered side by side, and why per-row anomalies do not apply.

Anomaly Messages

When the Data Diff check fires, it produces a single Shape Anomaly describing the dataset-level violation, with the per-row detail attached as Comparison Source Records. The check does not produce Record Anomalies; the diff is a property of the target as a whole.

The usual message names both containers with their datastores in parentheses:

N records differ between <container> (<datastore>) and <reference> (<reference datastore>)

When the comparison cannot get that far, the message says why instead:

Situation Message
The two containers hold different numbers of records <container> (<datastore>) and <reference> (<reference datastore>) hold different numbers of records: <observed> against <expected>
One side is empty <container> (<datastore>) has no records, but <reference> (<reference datastore>) holds <expected>
A compared field is missing on one side <container> (<datastore>) does not have the fields being compared: <field_a>, <field_b> and <field_c>
A compared field is stored as a different type <field> cannot be compared: it is stored as <type> in <container> (<datastore>) and as <other type> in <reference> (<reference datastore>)

Each message names the side at fault first, so the two containers swap places when it is the reference that is empty or missing fields. From four missing fields on, the message counts them instead of listing them: does not have <count> of the fields being compared: <list>. When the record count on the other side is not known, the empty-side message ends but <reference> (<reference datastore>) does.

The count has no singular form: one differing row still reads 1 records differ.

When a filter is set, the Shape Anomaly message names it at the end of its first sentence, as (applied to records where <expression>). Only the target's filter appears there; a filter set on the reference alone is not named. The exception is the message for two containers holding different numbers of records: when either side carries a filter, that message adds a sentence naming each filter against the container it applied to, ending in only when just one side is filtered.

What the Numbers Mean

  • N: the number of differing rows. When Diff Change Types restricts the reported statuses, only rows with a selected status are counted.
  • <observed> and <expected>: the row counts on the target and the reference, when the two differ.
  • <count> and <list>: how many compared fields are missing, and their names.

The Comparison Source Records hold every differing row, up to the scan's enrichment source-record limit.

Source Records Behavior

When Row Identifiers are configured, the per-row detail is rendered in the Comparison Source Records view, inside the anomaly's Source Records section. The columns, in order:

  1. Found in: a marker for each side, filled where the row exists and outlined where it does not.
  2. Status: an icon for added, removed, or changed (hover it to read the type).
  3. Row Identifier: the identifier value (or tuple) that pairs the target and reference rows.
  4. One column per listed field.

An added or removed row exists on one side only, so each of its cells shows that single value and the whole row is highlighted. On a changed row, only the fields the two sides disagree on are split into a left (target) and a right (reference) half and highlighted. Fields that agree show one value.

See Comparison Source Records for the full UI reference.

Custom Anomaly Description

Custom Anomaly Description does not apply to this rule. The option replaces the message on Record Anomalies, and Data Diff emits a Shape Anomaly only. The per-row detail lives in the Comparison Source Records view, not in the message.

See Also