Skip to content

Is Replica Of Troubleshooting

Deprecated: use Data Diff instead

The Is Replica Of rule is no longer maintained. Data Diff replaces it with the same row-by-row comparison plus change-type filtering. This page is kept as a reference for checks that already exist; new checks should use Data Diff.

Common problems when creating and running an Is Replica Of check, their causes, and how to resolve them.

Validation Fails When Creating the Check

Clicking Validate returns an error instead of a success message.

Cause: The rule could not run against the selected data. The most common reasons are a field that does not exist on the reference container, an invalid filter clause, or a container that failed to load.

Resolution:

  1. Review the error message: it explains what needs attention.
  2. Check the Filter Clause for typos: it must be a valid SQL WHERE expression for the selected container.
  3. If the message says the container is marked as Unloadable, the container was skipped after repeated operation failures. Follow the steps in Unloadable Container Error.

Every Row Is Reported as Different

The anomaly reports the whole dataset.

Cause: The two sides are not pairing, usually because no Row Identifiers are set or the identifier does not match across the containers.

Resolution: Set identifiers that are stable and identical on both sides. This is also a good moment to recreate the check as Data Diff.

Expected Rows Are Reported Every Run

A one-way flow keeps reporting rows that only exist on the target.

Cause: Is Replica Of has no way to restrict which change types are reported. Every difference counts.

Resolution: Migrate to Data Diff and set Diff Change Types to the statuses that matter, usually removed and changed.

Rounding or Casing Differences Are Reported

The check reports rows that differ only in the last decimals or in letter case.

Cause: Without a Comparator, the comparison is exact.

Resolution: Set the Numeric, Duration, or String comparator to tolerate the noise your pipeline introduces.

An Edited Check Keeps Behaving the Old Way

You changed the configuration but the anomaly list did not change.

Cause: Edits take effect on the next Scan. Saving the check does not re-evaluate the data, and anomalies raised under the previous configuration are not modified.

Resolution: Run a Scan on the container (or wait for the scheduled one). Old anomalies stay open until you triage them or a Full scan with Auto Resolve clears them. See What Happens to Existing Anomalies.

No Anomalies Although the Data Looks Wrong

A Scan ran, the data clearly breaks the rule, but nothing was reported.

Cause: One of these configurations is excluding the violations:

  • The check is in Draft status: Draft checks are not evaluated by Scans.
  • The Filter Clause excludes those rows before the evaluation runs.

Resolution: Confirm the check is Active and test the filter expression against the offending rows.