Recover a quarantined result

A quarantined materialization is stored, and readers should not use it. puppi assets prints quarantined next to the staleness state. puppi assets <key> names the check that failed. The rules for the check itself are in Quarantine.

There are two ways a result gets there, and the recovery is different for each.

A check failed during a run

The rows were written, the materialization was stored, and latest stayed on the previous result. The attempt status is failed_by_check. Its error_class is terminal, and the message starts with check failed:. Assets later in that run are blocked.

Fix the producer or the data, deploy if the code changed, and run again:

puppi deploy --env hello
puppi run --env hello

The quarantined row stays in the history. puppi rollback will not point at it.

A deploy quarantined the current result

Activating a deployment re-checks every declared schema against the columns stored on the current latest. No asset runs. When the stored columns no longer match, that materialization is marked quarantined while it is still latest.

Point the environment at the previous deployment. Activation runs the check again, and clears the quarantine when the stored columns match the restored schema. The commands are in Roll back a deployment.

On a strict environment, a later deploy that changes the declared schema has to name the asset:

puppi deploy --env hello --allow-contract-change core/customer

Point latest at an older copy

puppi rollback moves latest to an earlier materialization that is still retained and not quarantined. The engine keeps the data for the newest two.

puppi rollback core/customer
puppi rollback core/customer --to <materialization-id>

The command succeeds for a model in table mode and a source in full_refresh mode. It refuses an append source, an incremental model, a view, a destination, a quarantined row, and a row outside the newest two. Downstream assets are repointed or rebuilt. See Deploy and rollback.