Skip to content

Not Future Troubleshooting

Common problems when creating and running a Not Future 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 an invalid Filter Clause expression, a connection problem with the source, 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.

The Check Fires on Values Only Seconds Ahead

Rows are reported whose timestamps are barely in the future.

Cause: The clock on the system that wrote the row is ahead of the one evaluating it, or a time zone was applied in the wrong direction during ingestion.

Resolution: Fix the conversion or the clock upstream. Lowering coverage hides the symptom without correcting the data.

A Forward-Looking Field Is Always Reported

A scheduled or renewal date fires on almost every row.

Cause: The field is supposed to hold a future date, so the rule is the wrong fit for it.

Resolution: Point Not Future at the columns that record what already happened. For a forward-looking column, use Between Times or After Date Time to express the range you actually expect.

Rows With an Empty Date Are Not Flagged

Records with no date pass the check.

Cause: This is by design: NULL values pass. Not Future only constrains dates that are present.

Resolution: Pair the check with Not Null on the same field to also require presence.

An Array Field Is Reported as a Single Shape Anomaly

An array field produces one anomaly for the whole field instead of one anomaly per offending row.

Cause: On an array field the rule is evaluated element-wise as a field-level check, which always reports a Shape Anomaly, at any coverage. A row fails the assertion as soon as one element is ahead of now, and every failing row is summarized in that one anomaly's percentage and count.

Resolution: Use the Shape Anomaly's percentage and count to size the problem, then query the array field directly to locate the elements ahead of now.

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.
  • Coverage is below 100% and the failing fraction stayed within the tolerance, so the check passed.

Resolution: Confirm the check is Active and test the filter expression against the offending rows. Then review the coverage setting; see Coverage and Tolerance.

Expected One Anomaly per Row, Got a Single Rolled-Up One

Many rows failed, but the scan reported one Shape Anomaly instead of per-row Record Anomalies.

Cause: When the number of failing rows exceeds the scan's rollup threshold, the per-row findings are grouped into one rolled-up Shape Anomaly.

Resolution: This is expected behavior; the rolled-up anomaly carries sampled source records. To change the threshold, see Maximum Record Anomalies per Check.