Supavisor pooler auth_query never establishes a backend session on GitHub Actions runners (EAUTHQUERY / ECIRCUITBREAKER)

Start by reproducing supabase start on a fresh GitHub Actions ubuntu-latest runner, then connect through the printed Supavisor pooler string. Compare the pooled attempt with a direct PostgreSQL connection and monitor pg_stat_activity during retries. Done means the first pooled connection establishes successfully without EAUTHQUERY or ECIRCUITBREAKER.

Affected area

Auth

Supabase CLI version

2.117.0

Operating system

GitHub Actions ubuntu-latest runner (not reproduced locally — see Additional context for why)

Installation method

None

Command

supabase start

Actual output

FATAL: (EAUTHQUERY) user not found in the database

(under connection volume, same root cause surfaces as:)
FATAL: (ECIRCUITBREAKER) too many authentication failures, new connections are temporarily blocked

Expected behavior

Supavisor's auth_query connection should establish a backend session so pooled connections succeed immediately after supabase start, same as it already does on a local machine once its role-cache is warm.

Steps to reproduce

1. On a fresh GitHub Actions ubuntu-latest runner (no prior cache), install supabase CLI 2.117.0 via supabase/[email protected]
2. Run supabase start
3. Immediately attempt a connection through the printed Supavisor/pooler connection string (not the direct port)
4. Connection fails: FATAL: (EAUTHQUERY) user not found in the database — even though a direct (non-pooled) connection at the same moment confirms the role/password are correct

Crash report ID

No response

Docker and service versions

Additional context

Summary

On a fresh supabase start inside GitHub Actions (ubuntu-latest), the very first connection through the Supavisor pooler fails with FATAL: (EAUTHQUERY) user not found in the database, even though the role and password are confirmed correct at the Postgres level. Under connection volume the failure mode shifts to FATAL: (ECIRCUITBREAKER) too many authentication failures, new connections are temporarily blocked. Both are the same root cause: Supavisor's own auth_query connection never establishes a backend session at all in this environment — not a role/password/timing issue.

Environment

• supabase/cli version: 2.117.0
• Postgres image bundled with that version: 17.6.1.167
• Runner: GitHub Actions, ubuntu-latest
• Invocation: supabase start, then a pooled connection attempt via the Supavisor connection string immediately after

Evidence this is not a role/password/cache/timing issue

1. Role and password confirmed correct throughout the failure window — a direct (non-pooled) Postgres connection, run in parallel with every failure, confirms the role exists with the expected password at every timestamp EAUTHQUERY fired.
2. pg_stat_activity polled at 100ms resolution across a full ~135s retry window never once observed Supavisor's own connection establish, across four independent, timestamped EAUTHQUERY failures.
3. Not a warm-up/timing issue — six separate retry-interval tuning iterations, up to 135s total wait, were all insufficient. This isn't "give it more time," the pooler's auth_query connection simply never comes up in this environment.
4. Not reproducible on a local machine once Supavisor's role-cache is warm — the same theoretical race exists on a brand-new local supabase start too, but every local dev machine that has connected through the pooler even once already has a warm cache from that point forward, masking it. A fresh GitHub Actions runner never has a warm cache — every run hits it.
5. Under connection volume (a real test suite's fixtures), the identical root cause resurfaces as ECIRCUITBREAKER rather than EAUTHQUERY — consistent with the same underlying "auth_query backend never establishes," just a different Supavisor failure path once retries stack up.

Workaround in use (confirms root cause, not a fix)

Bypassing Supavisor entirely and connecting directly to Postgres on the direct/session-mode port, using the same role, produces identical results — 86 test files / 659 tests, all passing, byte-identical outcome to the pooled connection when it does work, RLS enforcement confirmed identical (verified this is not equivalent to using the migrator/superuser role, which would silently bypass RLS — deliberately used the same app_user/app_service role, not DIRECT_URL's privileged role). This confirms the issue is specifically in Supavisor's connection establishment on this runner class, not in the underlying database, role, or grants.

Ask

Has anyone else hit auth_query-never-establishes specifically on GitHub Actions runners with supabase start? Searched the existing issue tracker before filing — found no matching report. Happy to provide the CI run logs / pg_stat_activity polling data if useful for reproduction.