Concepts

Quarantine and reseed

Two failure classes need somewhere to go that is neither “apply it anyway” nor “stop everything.” Data that cannot be applied is quarantined. A destination that has fallen past retention is reseeded. Both are explicit states with named recovery commands rather than positions the system drifts into.

Quarantine

When a transaction cannot be applied — a constraint violation at the target, a schema contract breach, a checksum or manifest validation failure — the choice is between applying something wrong, blocking the flow indefinitely, or setting it aside. Trellara sets it aside.

Quarantine is isolating, not halting. The quarantined transaction stops advancing its own flow, and unrelated flows keep moving. At fleet scale this is the difference between one store's bad record and two thousand stores stopped behind it.

Finding it

trellara status --view diagnostics --config trellara.yml
trellara status --view report      --config trellara.yml

Quarantine records are durable evidence, not log lines. They appear in status output, in the fleet scorecard, in lake epoch metadata, and in the exported evidence package — which is why a quarantined source shows up in an epoch's completeness statement rather than being silently excluded from it.

Getting out of it

trellara repair plan --config trellara.yml
# or the flat spelling of the same command
trellara repair-plan --config trellara.yml

A repair plan names what is blocked and what would unblock it. There is deliberately no repair apply: the plan hands you the specific commands for the specific blockage rather than offering one button that means different things in different situations. Whatever it names — a reseed, a schema change, a config correction — replay afterwards is safe for the same reason every other replay is safe: apply is transaction-level deduplicated, so replaying a transaction that partially succeeded cannot double-apply it. See replay and deduplication.

Reseed

A destination that has been offline or blocked long enough falls past the source's WAL retention. The slot is gone or invalidated, the changes it needed no longer exist, and there is nothing to catch up from. Native replication's answer here is a full resync with no defined boundary. Trellara's is a reseed with one.

A reseed is a re-snapshot with an explicit visibility boundary and a verified handoff back to the live stream — which is to say, it re-enters the snapshot state machine rather than being a separate mechanism. The consistent LSN is recorded before copying, table progress is idempotent per relation, and the run cannot reach stream_handoff_ready until every table is copied at the same boundary.

trellara reseed --config trellara.yml
trellara stream locate-local --config trellara.yml
trellara verify --config trellara.yml

stream locate-local answers the question that decides whether a reseed is needed at all: is the position this consumer needs still present in the durable log?

At fleet scale

Reseed is not an incident at fleet scale; it is a routine state. A retail fleet has stores that go dark for a shift, and a database-per-tenant platform has tenants that migrate. Both surface as source states in the completeness model rather than as alerts:

A source in quarantined or reseeding makes every epoch it should have contributed to report the gap explicitly. See completeness epochs.