ℹ️ About Codex in GitHub

\\n
\\n\\n[Your team has set up Codex to review pull requests in this repo](https://chatgpt.com/codex/cloud/settings/general). Reviews are triggered when you\\n- Open a pull request for review\\n- Mark a draft as ready\\n- Comment \\\"@codex review\\\".\\n\\nIf Codex has suggestions, it will comment; otherwise it will react with 👍.\\n\\n\\n\\n\\nCodex can also answer questions or update the PR. Try commenting \\\"@codex address that feedback\\\".\\n \\n

\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"@codex review — confirmation pass on the folded fixes (tri-state Faulted routing so a DB outage degrades /health, required leaderLease ctor, connection dispose-on-open-failure, liveness-probe timeout). Same commit a056a80e.\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"\\n### 💡 Codex Review\\n\\nHere are some automated review suggestions for this pull request.\\n\\n**Reviewed commit:** `a056a80e6a`\\n \\n\\n

ℹ️ About Codex in GitHub

\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Require a session-preserving lease endpoint**\\n\\nWhen `ConnectionStrings:Default` points to a transaction-pooled proxy such as PgBouncer, `Pooling = false` only disables Npgsql's client pool; it does not pin commands to one PostgreSQL backend. `pg_try_advisory_lock` can therefore remain on a backend returned to the proxy pool while this object keeps `held = true`, and the later `SELECT 1` may execute on another backend, allowing multiple replicas to run as leaders. Require a direct/session-pooled endpoint for this lease—potentially via separate portable configuration—or use a mechanism compatible with transaction pooling.\\n\\nAGENTS.md reference: [AGENTS.md:L126-L130](https://github.com/mforce/cluckwork/blob/a056a80e6a978226526923c2e00fb2557994eeb8/AGENTS.md#L126-L130)\\n\\nUseful? React with 👍 / 👎.\",\"path\":\"src/Cluckwork.Infrastructure/Jobs/PostgresLeaderLease.cs\",\"side\":\"RIGHT\",\"line\":109}{\"type\":\"pull_request_comment\",\"body\":\"Confirmed and fixed in d05acda9c9e4d48bd64908b5ae5af20388def195. The lease now captures the backend PID that took the advisory lock in the SAME statement as the acquire (`SELECT pg_try_advisory_lock(@class,@obj), pg_backend_pid()`), and re-verifies it on every poll: if the serving backend PID no longer matches (a transaction-pooling proxy multiplexing the connection onto a different backend), it relinquishes leadership rather than trust the stale `held` flag. Net: fail-safe on every topology — never a silent double-run; under transaction pooling no instance leads stably and /health degrades (visible). New test `LeaderMigratedToAnotherBackend_RelinquishesTheStaleSession` proves it via an injected backend-PID probe; mutation-verified (disabling the PID-equality check turns it red). Making the lease WORK (not just fail safe) under a pooled deploy — a dedicated session-pinned lease endpoint — is tracked as #556. Full integration suite green (1251).\",\"path\":\"src/Cluckwork.Infrastructure/Jobs/PostgresLeaderLease.cs\",\"side\":\"RIGHT\",\"line\":109}{\"type\":\"pull_request_comment\",\"body\":\"@codex the transaction-pooling P1 is addressed in d05acda9 — the lease captures the lock's backend PID in the same statement as the acquire and relinquishes leadership on any poll served by a different backend (fail-safe, no silent double-run). Follow-up #556 tracks a dedicated session-pinned lease endpoint for pooled deploys. Please re-review.\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Keep the advisory lock pinned through the work**\\n\\nWhen `ConnectionStrings:Default` uses transaction pooling, the implicit transaction containing this acquisition ends before the method returns, so the proxy can immediately assign the lock-owning backend to another replica; because session advisory locks are reentrant, that replica's `pg_try_advisory_lock` can also succeed and both workers can enter `ProcessPendingJobsAsync` before either performs its next PID probe. Fresh evidence in d05acda9 is that the acquisition path still returns `Leader` immediately without a post-acquisition affinity check covering the ensuing work, so the later mismatch detection does not make this topology fail-safe. Require a session-pinned endpoint or another transaction-pool-compatible lease before returning leadership.\\n\\nAGENTS.md reference: [AGENTS.md:L126-L130](https://github.com/mforce/cluckwork/blob/d05acda9c9e4d48bd64908b5ae5af20388def195/AGENTS.md#L126-L130)\\n\\nUseful? React with 👍 / 👎.\",\"path\":\"src/Cluckwork.Infrastructure/Jobs/PostgresLeaderLease.cs\",\"side\":\"RIGHT\",\"line\":149}{\"type\":\"pull_request_comment\",\"body\":\"**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Synchronize the canonical deployment invariant**\\n\\nThis registration introduces the advisory-lock lease, but the canonical deployment guidance and its linked decision still state that the worker poll has no lease or advisory lock and list that absence as the #271 blocker. Leaving those architecture records unchanged makes subsequent scaling audits reason from behavior that this PR explicitly replaces; update them in the same change to describe the new lease and its transaction-pooling limitation while retaining the remaining single-instance blockers.\\n\\nAGENTS.md reference: [AGENTS.md:L126-L130](https://github.com/mforce/cluckwork/blob/d05acda9c9e4d48bd64908b5ae5af20388def195/AGENTS.md#L126-L130)\\n\\nUseful? React with 👍 / 👎.\",\"path\":\"src/Cluckwork.Api/Hosting/CluckworkJobServiceCollectionExtensions.cs\",\"side\":\"RIGHT\",\"line\":18}{\"type\":\"pull_request_comment\",\"body\":\"\\n### 💡 Codex Review\\n\\nHere are some automated review suggestions for this pull request.\\n\\n**Reviewed commit:** `d05acda9c9`\\n \\n\\n

ℹ️ About Codex in GitHub