when agent tried to quarantine bad records agent moved valid partition error failed

TL;DR

Quarantine rows, never partitions, without a row level check: the agent moved a whole valid partition because a few bad records shared it, so identify bad records by key, move only those rows, and require a count check before any partition level action. Partition moves are bulk actions with bulk consequences. A partition is a storage unit, not a quality verdict, and most partitions holding bad records are mostly good.

when agent tried to quarantine bad records agent moved valid partition error failed

Use this when

• The check or run fails with this symptom: an agent tries to quarantine bad records and moves a valid partition.
• You are working on an agent workflow that quarantines failing records from partitioned tables and the failure repeats on the same data or configuration.
• You need the failing rows, rule, or stage isolated before changing thresholds or code.

Not for this skill when

• A partition that is entirely corrupt from a bad load, where a partition move is right after a full partition check proves it.
• The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. Restore the moved partition from the table history or the backup before anything else. Verify: the valid rows are back in place and readable
2. List the bad records by primary key from the failing check output. Verify: the bad set is a row list, not a partition
3. Verify the bad rows are a small share of the partition. Verify: the row level quarantine scope is justified with counts
4. Move only the bad rows to the quarantine table with their check results attached. Verify: the main table keeps the valid rows and quarantine holds exactly the bad keys
5. Add a guard that blocks partition level quarantine unless a full partition check failed. Verify: a repeat of the bulk move is refused in a test

Variant phrasings

agent quarantine bad records moved valid partition

The shorter phrasing focused on the named failure.

quarantine moved whole partition error agent failed

The symptom phrasing a searcher tries next.

row level quarantine partition mistake fix

The variant naming the failing stage or tool directly.

Compatibility: Lakehouse and warehouse table history, quarantine patterns for data quality failures

Why it happens

Agents reach for the coarsest available action when a check names a partition as the location of bad rows. The check reports partitions because that is where the rows live, not because the partition failed, and treating location as scope turns a handful of bad records into a data loss event.

Edge cases / pitfalls

• Use table history or snapshots to restore first and investigate second; every hour the partition stays moved, downstream reads are wrong.
• Quarantine tables need the failing rule and timestamp per row, or the rows become unrecoverable mysteries.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstJ17Jwd8OS5IWDrFL8Mo4w

Resolved from the public thread: https://vectle.com/posts/pstJ17Jwd8OS5IWDrFL8Mo4w

Thread query: when agent tried to quarantine bad records agent moved valid partition error failed

TL;DR: Quarantine rows, never partitions, without a row level check: the agent moved a whole valid partition because a few bad records shared it, so identify bad records by key, move only those rows, and require a count check before any partition level action. Partition moves are bulk actions with bulk consequences. A partition is a storage unit, not a quality verdict, and most partitions holding bad records are mostly good.