CockroachDB 1.1.5 reports deferred schema errors at commit

A migration tool can submit valid SQL, receive no error and still fail to create the intended constraint. CockroachDB 1.1.5 fixes a case where the failure existed inside the database but disappeared before reaching the client. The trigger was how the transaction's statements were divided into requests. A schema-change statement and its final COMMIT did not have to arrive in the same query string.

The February 5 release notes describe errors from transactional DDL being silently swallowed in that arrangement. This is a consequential compatibility detail because client libraries commonly send statements through separate calls. Two applications can express the same transaction while producing different request boundaries on the wire.

I like CockroachDB's effort to make distributed transactions usable through familiar SQL clients. That interface needs an accurate account of failure as well as success. A migration framework cannot decide what to do next if the database loses an error that explains why the requested schema is unavailable.

The error arrives after the original statement

Andrei Matei's patch for pull request 21865 explains that schema changes queued in an explicit transaction could report errors only when their statement shared a query string with COMMIT. The remaining code tried to associate errors with earlier statement results. The patch removes that bookkeeping and reports the failure with the commit result.

The included regression test makes the sequence concrete. It creates rows with duplicate values, begins a transaction and requests a unique constraint on those values. The DDL execution itself returns without the duplicate-key error. The test then commits through a separate call and expects that call to report the duplicate-key failure.

This is a better explanation than saying that the database sometimes ignored invalid constraints. The constraint failure and its delivery to the client are distinct events. The bug concerns delivery under a particular request arrangement. That distinction points directly to what a client must observe when it uses the fixed version.

Request boundaries matter because the original statement's result may no longer be available when the deferred work fails. An implementation that tries to attach an error to an old result needs a policy for the case where that result has already been sent. The commit result provides a later response through which the failure can reach the caller.

For an application, this means checking the final transaction response remains necessary even when every earlier call appeared to succeed. A successful DDL submission does not establish that all deferred work completed successfully. The release changes which errors the caller can see at that later point.

Error reporting does not imply rollback

The patch description explicitly says that it does not resolve every problem with reporting schema-change errors. In particular, the error can misleadingly suggest that the transaction did not commit. The author also identifies a protocol-conformance issue that the patch leaves open. These limits matter when interpreting what the fix guarantees.

An application often uses a single error result to choose whether to retry a transaction. That is only valid if the error establishes the outcome the retry policy assumes. A failure in work associated with a committed transaction can require a different response from a transaction that never committed. Restoring the error message does not make those two cases equivalent.

My judgement is that this limitation belongs in the account of the release. Accurate delivery is progress, but the caller still needs to interpret the kind of failure reported. Saying that the fix makes transactional schema changes behave exactly like PostgreSQL would claim more than the patch supports.

The practical implication for migration bookkeeping is specific. A framework needs to know whether the intended schema exists and what transaction effects survived. It cannot infer both facts solely from the absence of an error on the original DDL call. The fixed commit response supplies information that was previously missing, while the documented semantic limitation still affects recovery decisions.

Failed restores also need a terminating path

Another 1.1.5 correction stops RESTORE jobs looping indefinitely during failure or cancellation when external storage is inaccessible. That addresses a different part of failure handling. An error must reach the caller, and work being abandoned must also be able to reach a finished failure state.

External storage availability makes cleanup harder because the failure path may depend on the same service that caused the original problem. If cancellation repeatedly waits on an unavailable dependency, the user can lose a way to conclude the operation. The release's narrow claim is that this particular indefinite loop is fixed. It does not promise that every restore failure has the same cause or recovery procedure.

Both changes are relevant to how automation interprets a maintenance operation. A schema migration needs its deferred error delivered, and a failed restore needs its failure or cancellation to terminate. In the DDL case, the restored signal still requires careful interpretation because the associated transaction may already have committed. That is the behavior an application needs to account for when moving to 1.1.5.