Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#6,855 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
35/100
issue の種類
バグ
明瞭さ
説明が足りない
活発さ
活発
技術スタック
github-actions, postgresql
領域
ci-cd, cli, databases

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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

主要言語
TypeScript
スター
2.4k
フォーク
531
平均マージ
1日 4時間
マージ済み PR（30日）
346

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

supabase/cli のほかの issue

supabase/cli の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。