[rudycelekli]

What this changes

A shared-app request is currently marked approved before its approval transaction starts. If writing the grant or its audience then fails, the request remains approved without access and cannot be retried.

Claim the pending request and write its approval in one transaction. Both direct approvals and request decisions first take the same transaction lock for the canonical Bot/app, before writing either row. This keeps their lock order consistent. Canonical app resolution uses the same transaction handle, so it does not open a nested pooled connection. A failed write rolls the decision back to pending; competing administrators still have one winner. An owner grant may only insert an absent approval: if an administrator wins a concurrent write, the owner returns no new audience and leaves that approval, its members, and request statuses untouched.

Where it runs

• New state that outlives a request? No new state; approvals and decisions remain in shared Postgres.
• What happens on the second replica? It reads the same committed membership and decision rows.
• Anything serialised? A canonical Bot/app advisory transaction lock precedes any row write in both paths. The conditional pending-request claim, approval, members, and covered-request updates share one transaction; no nested connection is acquired.
• Anything fanned out to a browser? No new fan-out.
• New listener, port, or schedule? None.

Boundary and audit

• Acting tool calls still pass through the existing gateway and shared-use gate.
• No new refusal/failure path is introduced; existing route audit behavior remains.
• No new client trust or additional audience. An owner cannot replace an administrator’s narrower approval during a concurrent grant.

Changelog

• Added an Unreleased entry.

Proof

Base 743649efc3f21d7bf0badbe6af2bcd5daedd97ce, head 85717f9101ed6ee0ab30a89288e1a579d374942c.

Two new real-database regressions inject SQL-trigger faults at the approval-row and member writes. Before: both fail because the request is already approved. After: both retain a pending request and no grant, then succeed on retry after removing the fault; the shared-use integration file and owner app-grant integration file pass together: 36 tests, 211 assertions, including the existing competing-admin race and owner grant/withdrawal controls. A further regression uses a real PostgreSQL row-lock gate and observes both concurrent sessions waiting before releasing it; a direct approval and request decision then both finish without a deadlock. Two further regressions reproduce the existing owner/admin race on unchanged upstream: an owner broadens an administrator’s owner-only or named-people audience to the team. Afterward, the administrator’s source and exact members remain, and the losing owner returns null. The schedule runs actual store methods with real SQL locks. Test triggers/functions, connections, and gates are released in finally.

Format, lint, workspace typecheck, the test-typecheck baseline guard, and build pass on this exact head. A separate routing candidate (d428f669f10e21700b6d5eb1fb14e90c9cc59cfe) on this same upstream base ran full test:ci: 11,017 passed, 210 skipped, two failed (routine-sweep concurrency expectation and recorder held-steps service-worker timing). Both isolated cases passed on unchanged base and that routing candidate; suite-order/timing causality remains unresolved. The full suite was not rerun on this head and no full green result is claimed.

Real integration tests use a dedicated disposable Postgres 15 database (hosted CI uses 17), with no live vendor calls or application data.

AI assistance: implemented and locally validated with OpenAI Codex. Hosted CI and maintainer review remain required.