Supavisor pooler auth_query never establishes a backend session on GitHub Actions runners (EAUTHQUERY / ECIRCUITBREAKER)
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 35/100
Línea de trabajo
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.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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
- On a fresh GitHub Actions ubuntu-latest runner (no prior cache), install supabase CLI 2.117.0 via supabase/[email protected]
- Run
supabase start - Immediately attempt a connection through the printed Supavisor/pooler connection string (not the direct port)
- 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/cliversion: 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
- 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.
pg_stat_activitypolled at 100ms resolution across a full ~135s retry window never once observed Supavisor's own connection establish, across four independent, timestamped EAUTHQUERY failures.- 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.
- Not reproducible on a local machine once Supavisor's role-cache is warm — the same theoretical race exists on a brand-new local
supabase starttoo, 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. - Under connection volume (a real test suite's fixtures), the identical root cause resurfaces as
ECIRCUITBREAKERrather thanEAUTHQUERY— 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.
- Lenguaje dominante
- TypeScript
- Estrellas
- 2.4k
- Forks
- 533
- Merge medio
- 1 d 5 h
- PR fusionados (30 d)
- 338
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de supabase/cli
-
🐛 Bug supabase/cli
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Los mantenedores suelen responder en 1 día
-
db schema declarative sync: no way to fail (non-zero exit) when the generated migration is destructiveQuizá libre de nuevo Un pull request para esta issue se cerró sin fusionarse. Abierto✨ Feature supabase/cli
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
Los mantenedores suelen responder en 1 día
-
stack: the HTTP gateway closes idle keep-alive connections after 5 s, so a client whose event loop is blocked gets ECONNRESET (`fetch failed`) on its next requestPosiblemente ocupada @7ttp la tomó hace 11 días. Abierto🐛 Bug supabase/cli
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
supabase/cli#6975 · 1 asignado ·
Los mantenedores suelen responder en 1 día
-
📘 Docs supabase/cli
Dificultad 1/5 Menos de una hora Aptitud para principiantes 88/100
supabase/cli#6974 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Migration error caret is missing or misplaced when the statement contains multibyte charactersAbierto🐛 Bug supabase/cli
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
Los mantenedores suelen responder en 1 día
Todos los issues de supabase/cli
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
needs triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
homarr-labs/homarr#7191 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
AvaProtocol/ava-sdk-js#276 ·
Los mantenedores suelen responder en 1 día
-
useFragment does not require `variables` when the fragment's variables type has required fieldsAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
apollographql/apollo-client#13493 ·
Los mantenedores suelen responder en 1 día