Release v0.1.59 · block/schemabot

Highlights

Apply claiming is now operation-level only — the apply-level claim path is gone. The operator_claim_operations server config key no longer exists and must be removed from any deployment values that still set it: config decoding is strict, so an unknown key makes the server exit at startup. (#933, #934)
ApplyStore.FindNextApply removed from the storage interface — embedders that claimed applies directly should claim through the operation ladder (ApplyOperations().FindNextApplyOperation) and then take the parent lease with Applies().ClaimApplyByID. (#934)

Operation-scoped drives execute statements in plan order — tasks for an operation-claimed apply were ordered newest-first, so a multi-statement plan ran in reverse. Ordering is now pinned at the storage layer. (#932)
Applies left behind their own settled operations are reconciled — an apply whose operations have all reached a terminal state while the apply's own state lagged is projected forward instead of blocking the target's next apply. (#916)
Stop-reconciliation claims are gated on lease staleness — a fresh, actively-driven apply can no longer be claimed out from under its driver. (#907)
Conflict checks require lease ownership before trusting local engine memory (#909)
Operation leases are released when the parent apply is transiently unclaimable, so a retry is not blocked behind a lease nobody is holding. (#924)

Apply and apply-confirm comment commands are dispatched durably — a restart or webhook redelivery between the command and its dispatch no longer loses the command. (#922)
check_run.completed re-folds are durable, so a re-fold survives a restart instead of leaving the aggregate check stale. (#919)
Unlock commands expose their retry disposition, letting the dispatcher tell a retryable failure from a permanent one. (#923)
A panicking webhook goroutine posts a fixed, user-safe comment instead of leaving the pull request with no response. (#921)

Per-database operator write scoping for forward-auth — the new operator_groups and operator_environments settings grant a team scoped write access (apply, rollback, plan, control commands, locks) to named databases in named environments, without granting deployment-wide admin. With neither key set, behavior is byte-for-byte unchanged. (#869)

Database operators get their own section on the review-required comment, so it is clear who can approve what. (#931)
Relayed control rejections name the apply they refer to (#905)

The execution verdict comes from Spirit's own checks rather than a parallel reimplementation, so refusals stay in step with the engine that enforces them. (#899)
Deploy requests keep retrying while the provider is still validating them, instead of failing the apply on a transient validating state. (#900)

status is ordered by last activity, so in-flight schema changes stay visible instead of being pushed off the list by older records. (#926)
Authenticated caller attribution keeps the CLI channel and hostname (#930)

A missing durable tenant is reported distinctly from a corrupted one, so the two failure modes can be triaged apart. (#920)

Spirit updated to v0.16.1 — brings the statement-level refusal reasons behind the engine verdict change above, plus DDL canonicalization improvements. The checkpoint table format is unchanged, so an in-flight copy interrupted by a redeploy still resumes from its checkpoint rather than restarting. Spirit also dropped its github.com/go-mysql-org/go-mysql fork replace in favor of upstream, and this release mirrors that — embedders carrying the same replace directive should drop it to stay aligned. (#925, #943)

Full Changelog: v0.1.58...v0.1.59