supabase / cli / 28508843826 / 1
65%
develop: 65%

LAST BUILD BRANCH: gh-readonly-queue/develop/pr-5760-77e9079c1a2796ed517782e3b5945ecdfeb2e445
DEFAULT BRANCH: develop
Ran
Files 229
Run time 9s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 65.019% (+0.02%) from 65.001%
28508843826.1

push

github

web-flow 
fix(cli): stop declarative sync hanging on edge-runtime container exit (#5714)

Fixes `supabase db schema declarative sync --experimental` (and other
pg-delta flows) hanging indefinitely at 0% CPU after the shadow-database
work completes.

Closes supabase/pg-toolbelt#312

There are two independent causes, both needed to unblock the command:

## 1. The Edge Runtime worker never exits

The pg-delta scripts run in a one-shot Edge Runtime container and rely
on the event loop draining for the worker to be destroyed and the
container to stop. The catalog-export script opens a real connection
pool (`createManagedPool`); when a keepalive handle stays registered
after `close()` resolves, the worker never exits, so the container never
stops. Only the error path force-closed the loop (`throw new
Error("")`); the success path did not.

Fix: force-close the event loop on the **success** path of every
pg-delta script once its output is flushed, so the worker is torn down
deterministically:

- `templates/pgdelta_catalog_export.ts` — catalog snapshot (the path
reported in #312)
- `templates/pgdelta.ts` — diff SOURCE→TARGET
- `templates/pgdelta_declarative_export.ts` — declarative file export
- `templates/pgdelta_declarative_apply.ts` — apply declarative schema
- the inline catalog-export script in `internal/db/pgcache/cache.go` —
the `db start` / `db push` migrations-catalog cache path

The byte-for-byte embedded copies in `legacy-pgdelta.deno-templates.ts`
are kept in sync.

## 2. Following the container log stream hangs under podman

With the worker now exiting, the container stops — but the parent still
hung for podman users. A goroutine dump on the stuck `__catalog`
subprocess showed the block in `stdcopy.StdCopy` reading the
`Follow:true` Docker log stream (`DockerStreamLogs`): podman's
`/containers/<id>/logs?follow` endpoint does not close when the
container stops, so the read never gets EOF and blocks forever. Docker
closes it, which is why this only reproduce... (continued)

11007 of 16929 relevant lines covered (65.02%)

10.44 hits per line

Source Files on job 28508843826.1