Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
  • Is something wrong?
#6,855 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Needs clarification
Activity status
Active
Tech stack
github-actions, postgresql
Domain
ci-cd, cli, databases

Research direction

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.

Written by the indexing model from the issue text.

Description

🐛 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.

Dominant language
TypeScript
Stars
2.4k
Forks
526
Avg merge
1d 2h
Merged PRs (30d)
307

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from supabase/cli

All issues in supabase/cli

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.