Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

stack: rest readiness probe (GET /) never passes when a db_pre_request hook rejects requests without an app header

未关闭
  • 哪里不对？
#7,215 0 条评论 0 个 reaction 已指派 1 人 在 GitHub 查看

维护者通常 1 天内回复

@7ttp 已经在做这个了。

开始于 2026年10月17日。

  • #7216 来自 @7ttp —— 未关闭

评估

难度
3/5
预计耗时
1-2 天
新手友好度
66/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
活跃
技术栈
postgresql, typescript
领域
backend, devops

调研方向

Find the experimental stack rest service recipe and its readiness probe; compare it with the Docker recipe’s PostgREST admin port configuration and the native runtime’s exposed ports. Check the readiness and service startup tests first. Done means the service becomes ready when PostgREST is serving even if db_pre_request rejects an anonymous GET /, and the eager and lazy startup cases pass.

由索引模型根据 Issue 内容生成。

描述

🐛 Bug supabase/cli
Affected area

Local development: experimental stack engine ([experimental] stack = true), rest service readiness.

Supabase CLI version

2.121.0 and 2.122.0-beta.1

Operating system

Linux x86_64 (glibc 2.44)

Installation method

npx

Command

supabase start --runtime native --eager (also reproduced with lazy start)

Actual output

With --eager, start fails:

ExperimentalStackStartError: Composition start had failures
rest (...): ... is not ready: rest HTTP readiness timed out
Recent stdout:
127.0.0.1 - anon [...] "GET / HTTP/1.1" 403 71 "" ""
127.0.0.1 - anon [...] "GET / HTTP/1.1" 403 71 "" ""

With the default lazy start, supabase start succeeds, but the first Data API request (which carries the header the hook requires) waits about 60 s and then returns 502 from the gateway, because rest never becomes ready. The same request sent directly to the PostgREST process returns 200.

Expected behavior

rest is reported ready once PostgREST is up and serving, independent of how the project's db_pre_request hook answers an anonymous GET /.

The rest recipe hardcodes healthPath: "/" on the data port. GET / runs the configured db_pre_request function, so any project whose hook rejects requests without an application header (for example a shared proxy-secret check) can never pass readiness. PostgREST has an admin server with GET /ready for this purpose; the Docker recipe already sets PGRST_ADMIN_SERVER_PORT. In the native runtime I only saw the data port listening. Probing /ready on the admin port, or treating any HTTP response from the data port as "up", would fix it.

Steps to reproduce
  1. SUPABASE_EXPERIMENTAL_STACK=1 supabase init
  2. Add supabase/migrations/20260101000000_pre_request_hook.sql:
create schema hooks;
create function hooks.check_request() returns void language plpgsql as $$
begin
  if current_setting('request.headers', true)::json->>'x-app-secret' is distinct from 'expected' then
    raise sqlstate 'PGRST' using
      message = json_build_object('code', 'APP_403', 'message', 'Unauthorized.')::text,
      detail = json_build_object('status', 403, 'headers', json_build_object())::text;
  end if;
end;
$$;
grant usage on schema hooks to anon, authenticated, service_role;
grant execute on function hooks.check_request() to anon, authenticated, service_role;
alter role authenticator set pgrst.db_pre_request = 'hooks.check_request';
notify pgrst, 'reload config';
create table public.notes (id int primary key);
grant select on public.notes to anon;
  1. supabase start --runtime native --eager fails with rest HTTP readiness timed out.
  2. Control: without that migration, the same command exits 0.
  3. Lazy variant: supabase start --runtime native, then curl -H 'x-app-secret: expected' -H "apikey: $PUBLISHABLE_KEY" "$API_URL/rest/v1/notes" returns 502 after about 60 s.
Crash report ID

N/A

Docker and service versions

Native runtime (PostgREST 16.4, Postgres 17). The Docker runtime uses the same recipe healthPath.

Additional context

The default (non-stack) engine works with the same hook, so this blocks adopting per-worktree stacks for projects that gate the Data API in a pre-request hook.

主要语言
TypeScript
星标
2.4k
派生
537
平均合并
21 小时 24 分钟
30 天内合并 PR
378

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

supabase/cli 的其他 Issue

查看 supabase/cli 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。