Skip to content

Max Partition Size Troubleshooting

Common problems when creating and running a Max Partition Size 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 container. The most common reasons are a threshold that is missing or not a number, or a container that failed to load.

Resolution:

  1. Review the error message: it explains what needs attention.
  2. Confirm Maximum partition size holds a number: it is the only property the rule takes, and it is required.
  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 Every Partition

Every loaded partition is reported, on every Scan.

Cause: The threshold is sized for the whole delivery rather than for one partition. On a file container that loads many files per Scan, each file is evaluated separately.

Resolution: Set the Maximum partition size to the size of a single partition. To bound the container as a whole, use Volumetric instead.

There Is No Field Picker on the Form

The form shows no field to select.

Cause: This is expected. The rule counts records in a partition and never reads a column, so it takes no field.

Resolution: Nothing to change. Attach the check to the container and set the threshold.

The Anomaly Lists No Source Records

Opening the anomaly shows the message but no violating rows.

Cause: The rule raises a partition-level Shape Anomaly. There is no offending row, only a partition whose record count is outside the threshold.

Resolution: Read the partition name and the two counts in the message. Use a value-level check when you also need to see the records.

The Count in the Message Does Not Match the Table

The reported count differs from a SELECT count(*) on the container.

Cause: The check counts the records the Scan loaded from that partition, not everything in the container. On an Incremental scan that is only the new slice.

Resolution: Compare against the partition the Scan read. See Read Strategies for what each strategy loads.

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 is keeping the partition under the ceiling:

  • The check is in Draft status: Draft checks are not evaluated by Scans.
  • The Scan loaded less than you expect. The rule counts what was loaded from a partition, so an Incremental scan that read only the new slice can stay under a threshold the full partition would break.

Resolution: Confirm the check is Active, then compare the threshold against what the Scan actually loaded. See Read Strategies.