fix: harden sync error handling, unwrap the gateway envelope, and report RLS denials

[marcobambini]

Release 1.1.4. The substance is @marcobambini's audit hardening (e0ebb77); everything after it is follow-up work from running that hardening against CI and then reviewing it.

Sync error handling (e0ebb77)

The headline fix is a silent data-loss path: cloudsync_payload_apply reassigned rc on every row, so an error on one row was overwritten by any later success. A failed write could report success and advance the receive checkpoint, dropping the changes for good. Errors are now sticky.

Alongside it: little-endian IEEE754 byte order made explicit for PK doubles on every architecture, per-statement SPI tuple-table ownership, block-LWW rollback on write failure, 64-bit clocks above UINT32_MAX, network deadlines, a 256 MiB decompressed-payload cap, and Node ia32 rejection. Details in docs/internal/audit-regressions.md.

Gateway data envelope (c6200a8, a1f3ea3)

Scoping key lookups to a single object was correct, but seven reads take their key from a raw response body, and per API.md the gateway wraps every success payload in {"data": <payload>}. Root-scoped, they stopped resolving — every send failed with missing 'url' in upload response while all local suites stayed green, because no fixture used the real shape.

Affected: the upload URL, the three sync-state fields, and both failure stages on the send path, plus failures.check on the receive path. Each now resolves the payload first via json_response_payload, mirroring the unwrap /check already did. jsmn_find_key is unchanged from e0ebb77 — the hardening is intact, and envelope handling is explicit per call site rather than hidden in a shared helper.

RLS denials: skip, advance, report (f68c523, 067f3fb, 4a1cfd2)

A denial suppressed the receive checkpoint, which gave neither progress nor a signal: the rows are permanently not this site's to hold, so the next check re-delivered them, they were denied again, and one denied row stalled every later change behind it. In a chunked batch it was worse — policy_denied was a local of one apply call, so a denial in a non-final chunk suppressed a checkpoint that was already a no-op and the final chunk advanced past the denied rows anyway.

Denied entries are now counted, skipped, and the cursor advances. The count accumulates across the drain and is reported as receive.denied, so discarding stays visible. receive.rows reports rows actually written, matching what API.md has always documented.

Deliberately not an error even when every row is denied: a single-row payload belonging to another user is denied in full and is a correct outcome, which tests 27 and 29 already assert.

Known gap: this does not extend to a value large enough to be fragmented. Making the v3 path skip a denial leaves PostgreSQL's transaction unusable — the next statement fails with buffer pin is not owned by resource owner — and neither a savepoint around the per-value apply nor dropping the staged-fragment delete recovers it. 067f3fb tried; 4a1cfd2 reverts it. 58_v3_denied_checkpoint.sql builds a real fragmented payload, applies it under a WITH CHECK policy, and pins the current behaviour with a note to flip the assertion once the apply leaves a recoverable state.

Block-column failures (6bf127b)

Reading the row back is part of writing a block column, and a row its own session cannot select could not sync anyway — so the failure stays fatal, but it has to be legible. Five paths returned a bare code with no message, two of them the raw negative from pk_decode_prikey, which is not a DBRES value at all. databasevm_step clears the error text on entry, so PostgreSQL aborted the user's INSERT with an empty errmsg. Each now names the table and column.

Artifact transfer deadlines (7077df7)

CURLOPT_TIMEOUT applied to both pooled handles, but a presigned S3 URL is not an API endpoint, so artifact transfers inherited the 300-second cap: 256 MiB inside 300s demands a sustained ~875 KB/s. API calls keep the elapsed-time cap; artifact transfers now abort after 60 seconds below 1 KB/s — which also catches a real stall five times sooner — with a 1-hour backstop, since nothing can cancel a transfer in flight.

Also

• merge_flush_pending replaced a failing commit's real error with a generic string (b4a5b3f).
• Test 39 encoded the old lenient contract and aborted under ON_ERROR_STOP once errors became sticky (9d89fbb).
• changelog.yml's tag filter is restored: widening it made the workflow fire, but the called workflow derives the version with ${GITHUB_REF#refs/tags/v} and rejects our unprefixed tags. Fixing that needs a change in changelog-action, so the filter goes back and a note records why.
• API.md documents denied in both receive shapes and all six samples.

Verification

• Full CI green on 5171b77: 37 pass, 1 skipped (release, correct on a branch)
• PostgreSQL 15/17/18 484/484, zero failures
• SQLite unit suite passes with Memory Leaks Check: OK
• make postgres-check-migration: 1.1.3 -> 1.1.4, SQL surface identical, no migration script required
• Each behavioural fix has a negative control — the regression tests were confirmed to fail against the old behaviour before being kept

Open

• endian-unittest cannot detect anything: pk.c no longer references any endian-conditional symbol, so the forced-big-endian object is byte-identical to the normal one (verified by hash). The target is also unreachable from test: and from CI. Delete it or make it real — @marcobambini's call, since it is his audit scaffolding.
• The gateway's error envelope ({"errors":[...]}) is never parsed by the client — error bodies are passed through verbatim — so root-scoped lookups cannot affect it. That also means a server error surfaces as a raw JSON blob rather than its detail string. Pre-existing, worth a follow-up.

🤖 Generated with Claude Code

https://claude.ai/code/session_01CCE6B54Qtf3UsaCVAJtVQF