fix: ADR 0050 callback-error precedence, and the honest limits of transaction control
CI / verify (pull_request) Successful in 1m4s
CI / infrastructure-smoke (pull_request) Successful in 38s
CI / migration-smoke (pull_request) Successful in 1m54s
CI / image-build (pull_request) Successful in 22s
CI / deploy-smoke (same-origin) (pull_request) Successful in 51s
CI / deploy-smoke (split) (pull_request) Successful in 1m37s
CI / verify (pull_request) Successful in 1m4s
CI / infrastructure-smoke (pull_request) Successful in 38s
CI / migration-smoke (pull_request) Successful in 1m54s
CI / image-build (pull_request) Successful in 22s
CI / deploy-smoke (same-origin) (pull_request) Successful in 51s
CI / deploy-smoke (split) (pull_request) Successful in 1m37s
Narrow contract and implementation adjustments from review. No SDK, manifest, packaging, or Signage work. Callback-error precedence: - A transaction or savepoint callback that rejects keeps its own error, even while sibling work it started is still settling (one failed half of a Promise.all). Core drains that work, rolls back, and never commits or releases. - A callback that resolves with work outstanding (a forgotten await) still fails with MODULE_DATABASE_SCOPE_WORK_OUTSTANDING and rolls back. Transaction-control SQL: - ADR 0050 forbids it through query() as a conformance rule for trusted code, not a security guarantee. Core does not parse SQL, so PostgreSQL has run the statement before Core sees it. Core detects the violation from the command tag or the transaction status, and claims nothing it cannot do: a module's own COMMIT has committed. - After a violation, the transaction's scopes refuse every later statement without sending it (it would otherwise autocommit). Core never commits the transaction itself, and the connection is destroyed rather than reused, for top-level violations too. - The commit and rollback guarantees apply to conforming use. Duplicate object-mode columns: documented as found only after execution, so a mutation can have taken effect; atomicity needs an ABI transaction. Tests prove each of these against PostgreSQL: Promise.all failures in a transaction and a savepoint keep 23505; a forgotten await still rolls back; a module COMMIT's prior work is committed while nothing after it runs; a backend PID changes after every violation; duplicate RETURNING columns persist at the top level and roll back in a transaction. ADR 0050 stays Accepted: the executor conforms to the revised text. Co-Authored-By: Claude Opus 5.5 <[email protected]>
This commit is contained in:
co-authored by
Claude Opus 5.5
parent
6db50516b7
commit
317a4ce410
@@ -522,7 +522,12 @@ because every claim is a property of PostgreSQL or of the protocol:
|
||||
- commit, rollback, isolation levels, read-only, no retries, and an aborted transaction never being
|
||||
committed;
|
||||
- callback-scoped savepoints;
|
||||
- a forgotten `await` rolling back instead of committing;
|
||||
- a forgotten `await` rolling back instead of committing, while a rejected callback (one half of a
|
||||
failed `Promise.all`) keeps its own error;
|
||||
- transaction-control SQL sent through `query` detected only after PostgreSQL has run it: Core
|
||||
cannot undo a module's own `COMMIT`, so the suite pins what it does do: it refuses everything
|
||||
after, never commits, and destroys the connection;
|
||||
- duplicate object-mode columns found only after a mutation ran, unless it ran in a transaction;
|
||||
- revoked executors reaching nothing.
|
||||
|
||||
The suite's database is created with deliberately hostile defaults: a non-UTC time zone, a non-ISO
|
||||
|
||||
Reference in New Issue
Block a user