Destructive Operations

StreamBuild provides two destructive operations: Adopted or external relations are never dropped. Historical deployment metadata can retain an absent relation in reset evidence, but it cannot authorize deletion when a live relation later reuses the same name. A live relation requires matching current-manifest structure or a recorded ownership generation. A later build recreates resources that still exist in the authored project.

​

Review a frozen impact plan

Planning is read-only. The plan records:

• target and physical database
• original pipeline selection and explicitly included downstream closure
• affected models and physical relation kinds
• approximate active-part bytes and part counts where available
• managed-source and replay-data inclusion
• manifest, warehouse, and plan fingerprints
• deterministic confirmation challenges and expiry

Plans and their review state are durable in the StreamBuild control store, including standalone CLI plans. A plan remains actor-bound and single-use across development-server restarts and multiple server workers until it expires or is consumed. If an unselected downstream pipeline depends on the selection, planning blocks. StreamBuild reports the complete required closure but never adds it silently. Include those pipelines explicitly and create a new plan.

​

Pass both confirmation gates

Every execution has two server-enforced gates:

1. Review the exact frozen plan and explicitly continue.
2. Type the exact challenge values from that plan.

Challenge selection is deterministic: A production target reset also requires the exact value PRODUCTION. Mark non-standard production target names in committed configuration with production = true; local configuration cannot remove or add this classification.

​

Execution and evidence

After exact confirmation, StreamBuild acquires the target mutation lock and replans. A manifest, selection, ownership, binding, or warehouse-structure change rejects the operation before the first drop. Normal ingestion growth does not invalidate a plan. StreamBuild durably records the exact actor, challenge submission, and statement set before atomically consuming the plan once and starting warehouse mutation. Dependency validation scans view and materialized-view definitions across every ClickHouse database. An unmanaged dependant in any database blocks deletion. The authenticated account is also reloaded from the control store and must still be active with the built-in admin role at execution time. Owned relations are dropped in reverse dependency-safe order. ClickHouse DDL is not graph-wide transactional, so a failure can leave a partial result. StreamBuild does not hide that state or retry it as a fresh plan. Runs retains the actor, reviewed and confirmed timestamps, expected and submitted challenges, fingerprints, estimated bytes, every statement and timing, completed and pending sequences, errors, and remaining objects. An interrupt after plan consumption follows the same terminalization path: StreamBuild inspects the catalog, recovers an ownership tombstone when a DROP reached its postcondition, records the terminal state, and only then propagates the interrupt. If the residual catalog cannot be read after a partial mutation, Runs records the residual state as unavailable rather than claiming that no objects remain. Target mutation locks encode their owner in the atomic ClickHouse namespace claim and use an atomic table exchange when releasing. Locks do not expire automatically. After a crashed owner, keep the target quiescent and recover the lock explicitly; age-based takeover could overlap a server-side ClickHouse query that outlived its client. Resetting warehouse source relations does not call Kafka administration APIs. Consumer-group offsets remain broker-managed and are not silently reset.