Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
#6,855 0 comentarios 0 reacciones 0 asignados Ver en GitHub

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
Tipo de issue
Error
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
github-actions, postgresql
Área
ci-cd, cli, databases

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

🐛 Bug supabase/cli
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.

Lenguaje dominante
TypeScript
Estrellas
2.4k
Forks
533
Merge medio
1 d 5 h
PR fusionados (30 d)
338

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de supabase/cli

Todos los issues de supabase/cli

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.