chore(repo): sync develop into next by supabase-cli-releaser[bot] · Pull Request #7158 · supabase/cli

supabase-cli-releaser · 2026-10-14T16:16:04Z

Merging develop into next conflicts. This branch starts at the tip of develop (e0f7bef); next is at b068add.

Conflicting files:

apps/cli/src/command-internal/test-db.integration.test.ts
apps/cli/src/commands/inspect/db/table-index-sizes/table-index-sizes.command.ts
apps/cli/src/commands/inspect/db/total-index-size/total-index-size.command.ts
apps/cli/src/commands/inspect/db/total-table-sizes/total-table-sizes.command.ts
apps/cli/src/commands/inspect/report/report.integration.test.ts
apps/cli/src/commands/migration/list/list.command.ts
apps/cli/src/commands/migration/repair/repair.command.ts
apps/cli/src/commands/migration/squash/squash.command.ts

To resolve:

git fetch origin
git switch sync/develop-into-next
git merge origin/next
# resolve the conflicts, then commit
git push origin sync/develop-into-next

Approve to fast-forward next; do not use the merge button.

Maps `migration list`, `fetch`, `repair`, `up`, `down`, `squash` and `new`, plus `test db` and `test new`, to the Management API operations they call, so a scoped access token can be granted per command. The six database commands declare `dbConfig` and the linked-project cache under the linked target. `list`, `fetch` and `repair` default to linked; `up`, `down` and `squash` default to local, where no request is made. `--password` (list, repair, squash) removes the login-role call, and `--project-ref` adds the pooler config fetch. `migration new` and `test new` make no calls. `test db` declares the same database config as its hidden alias `db test`. Each command's integration tests run once through the real database config resolver and linked-project cache and check the recorded requests against the declarations. That covers the linked run (pooler config, login role, project lookup for the cache), the local run (no request; for `up`, `down`, `squash` and `test db` a login-role request is also rejected under the default flags), `migration up --linked=false`, and `--password` on `list`, `repair` and `squash`. Also corrects the stale Management API routes in `migration squash`'s `SIDE_EFFECTS.md`. No operations without FGA permissions and no shared block changes. `--linked=false` is exercised through the real layers only on `migration up`. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Sonnet 5.5 <noreply@anthropic.com>

Maps the Management API permissions for the `inspect` commands: the 25 `inspect db` subcommands and `inspect report`. All 25 `inspect db` subcommands run one shared query runner, so they share one declaration: the database-config block (`dbConfig`) with `linked` as the default database target. `inspect report` declares the same block plus `--output-dir`, which makes no API call. On `--local` and `--db-url` neither command calls the Management API. On the linked project they fetch the pooler config (with `--project-ref`) and create a temporary login role unless a database password is already available. Neither command fills the linked-project cache or prompts for a project. Tests run the real database-config resolver, record the requests it makes and check them against the declarations. One linked `db-stats` run is checked against all 25 `inspect db` declarations, taken from the real command tree; `--linked=false`, an empty `--project-ref` and the `--local`/`--db-url` no-request cases are covered separately, as is `inspect report`. Shared pieces: no block or model change, no `oneOf`/`is` conditions of its own, no new operations, no change to `OPERATIONS_WITHOUT_FGA`. The 26 commands leave the pending list. Docs: `inspect db`'s `SIDE_EFFECTS.md` had the wrong login-role and network-ban routes and no concrete pooler route; `inspect report`'s claimed a linked-project cache write that nothing performs. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Sonnet 5.5 <noreply@anthropic.com>

…ase-oss (#7124) ## Summary Claude-resolved `sync/develop-into-next` PRs now get approved without a maintainer when the merge is clean in practice: - every check except `Require fast-forward` is green on the head, - the AI review posted a review on that exact head, - Claude fixed or declined every finding (declining the ones the merge did not introduce), - no `.github/` workflow suggestions are waiting. `sync-repair` plans an `approve` action in that state, and a new `approve` job submits an approval for that commit as `supabase-oss` through the `auto-approve` environment. The approval runs `fast-forward.yml` as usual, which re-checks the approver, the head and the checks before moving `next`. A head moved past the reviewed commit, by a repair commit or a maintainer push, is never re-reviewed, so it still waits for a person. The job skips if the head moved or `supabase-oss` already approved that commit. This reverses the documented rule that the bot never approves sync heads; `release-process.md` records the new accepted decision. Reviewers should confirm the `auto-approve` environment's branch rule lets `sync-repair` runs on `develop` deploy. ## Linked issue - [x] I'm a Supabase maintainer. ## Checklist - [x] The PR title follows Conventional Commits. - [x] Tests added or updated for the change. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>

## TL;DR patches a few flakes: - **native launcher pin** failed when a cache sweep briefly locked the artifact pin. it now waits up to 2s like the owner's own pin, and a failed launch carries the launcher's stderr. - **native Realtime** could be marked ready by another process answering its port. it now waits for its own bind line like Pooler, so a lost port relaunches. - **HostProcess argv** blocked the event loop on a slow Windows CIM query. i've made the read async with a named guard. - **Owner.logs resume** could read history before the first record landed. it now waits for output first. - **pinned ports** in the Network tests could land on RDP 3389 on Windows. they now stay under 3000. - **Owner.analytics** now says whether the events table or the row was missing. ## ref: - spotted in: [launcher pin](https://github.com/supabase/cli/actions/runs/38494662586/job/115627588416) [native Realtime](https://github.com/supabase/cli/actions/runs/38415198781/job/115357678754) [HostProcess argv](https://github.com/supabase/cli/actions/runs/38399326861/job/115302578574) [Owner.logs](https://github.com/supabase/cli/actions/runs/38373564250/job/115216209193) [pinned ports](https://github.com/supabase/cli/actions/runs/38536558032/job/115761323171) [Owner.analytics](https://github.com/supabase/cli/actions/runs/38232117245/job/114753854349) --------- Co-authored-by: Andrew Valleteau <avallete@users.noreply.github.com>

# Conflicts: # apps/cli/src/command-internal/test-db.integration.test.ts # apps/cli/src/commands/inspect/db/table-index-sizes/table-index-sizes.command.ts # apps/cli/src/commands/inspect/db/total-index-size/total-index-size.command.ts # apps/cli/src/commands/inspect/db/total-table-sizes/total-table-sizes.command.ts # apps/cli/src/commands/inspect/report/report.integration.test.ts # apps/cli/src/commands/migration/list/list.command.ts # apps/cli/src/commands/migration/repair/repair.command.ts # apps/cli/src/commands/migration/squash/squash.command.ts

supabase-cli-releaser · 2026-10-14T16:21:10Z

Claude resolved the merge of `next`

I resolved all eight conflicted files and no conflict markers remain. I haven't run any checks; those run next. The conflicts came from two changes overlapping: develop's command-permission mapping (withPermissions) and next's changes. Next removed three inspect db commands, moved migration flags to CLI config keys, and replaced cliConfigProviderLayer with configValuesLayer in tests.

File	Resolution
`apps/cli/src/commands/inspect/db/table-index-sizes/table-index-sizes.command.ts`	Kept next's removed-command stub. Added an empty `withPermissions` declaration because the stub makes no Management API calls, and listed the four inspect flags as having no API effect, so the permission-completeness test still passes.
`apps/cli/src/commands/inspect/db/total-index-size/total-index-size.command.ts`	Same as table-index-sizes: next's removed stub plus an empty permission declaration.
`apps/cli/src/commands/inspect/db/total-table-sizes/total-table-sizes.command.ts`	Same as table-index-sizes: next's removed stub plus an empty permission declaration.
`apps/cli/src/commands/migration/list/list.command.ts`	Kept both sets of imports: develop's permission imports and next's `withCliConfigFlags`/`CliConfigKeys`. The body had already merged cleanly.
`apps/cli/src/commands/migration/repair/repair.command.ts`	Kept both sets of imports (develop's permissions and next's CLI config flags).
`apps/cli/src/commands/migration/squash/squash.command.ts`	Kept both sets of imports (develop's permissions and next's CLI config flags and values layer).
`apps/cli/src/command-internal/test-db.integration.test.ts`	Kept both sets of imports: develop's permission-drift and real-layer helpers, and next's `cliConfigValuesTestLayer`, which is used in the layer setup.
`apps/cli/src/commands/inspect/report/report.integration.test.ts`	Always provides next's `configValuesLayer()`. In real-layer mode it also adds develop's `ConfigProvider` with `SUPABASE_ACCESS_TOKEN`, in place of the `cliConfigProviderLayer` that next removed.

Decisions for @supabase/cli. Confirm them, or push a change to this branch:

Develop mapped permissions on inspect db table-index-sizes, total-index-size and total-table-sizes, but next turned them into removed-command stubs. Which permissions should they declare? Chose: An empty mapped declaration: no operations, with db-url, linked, local and project-ref listed as having no API effect. The stubs fail before any API call, so develop's INSPECT_DB_PERMISSIONS would overstate what they do, and the completeness test requires every leaf command to be either declared or listed as pending.

Quick checks. The merged tree passes check:all and unit tests.

Approve to fast-forward next once checks pass (workflow run).

github-actions

🤖 AI Review

Verified all three findings from both independent reviews. Confirmed one deterministic integration-test failure and two polish issues. No duplicates were present. Corrected the documentation finding to line 361 in the checked-out file. Verification was by code inspection; tests were not run because dependencies are absent.

Findings

Severity	Location	Category	Sources	Claim
🟠 MAJOR	`apps/cli/src/commands/inspect/db/inspect-query.integration.test.ts:503`	`test-correctness`	codex	The all-leaves permission test checks the three removed inspect commands against linked-database API requests, causing the test to fail.
⚪ NIT	`.github/workflows/ai-review.yml:68`	`dead-code`	claude	The resolve job still exports an unused head_ref output after both PR checkouts switched to head_sha.
⚪ NIT	`apps/cli/docs/release-process.md:361`	`docs`	claude	The sync-approval paragraph repeats "This is an accepted decision:" for two distinct tradeoffs, making the wording unnecessarily repetitive.

Stats

Claude findings: 2 · Codex findings: 1 · Confirmed: 3 · Refuted: 0 · Uncertain: 0

Models: claude-opus-5-5 + gpt-6.1-sol · Trigger: manual · Workflow run

This review runs once per PR. A maintainer can request another with a /ai-review comment.

supabase-cli-releaser · 2026-10-14T16:35:49Z

Claude repair round

The integration failure was a semantic conflict: develop's all-leaves permission test in inspect-query.integration.test.ts sent every inspect db leaf through the shared runner, but next turned table-index-sizes, total-index-size and total-table-sizes into removed commands that declare no operations. The test now checks those three separately, expecting them to make no API calls, and the "Run unit and integration tests" job failed only because this test did.

1 findings fixed, 2 declined (workflow run).

github-actions · 2026-10-15T11:12:34Z

next moved since approval, so I merged the latest next into the approved head and landed it as 8e5a4cb.

…oves (supabase#7205) ## Summary **TL;DR:** Since supabase#7124, no Claude-resolved `sync/develop-into-next` PR has been auto-approved by `supabase-oss`. Claude's repair commit moves the head past the only AI review, so the approval gate (review head must equal PR head) never passes. This adds one bounded AI re-review after a repair, and when `next` moves and conflicts at fast-forward time, Claude re-resolves the same PR instead of asking a maintainer. **Before** ```mermaid flowchart LR A[AI review on X] --> B[Claude repair pushes Y] B --> C{"review head == Y?"} C -- no --> D[skip forever] D --> E[human approves] F[next moved + conflict] --> G[ask human to resolve] ``` **After** ```mermaid flowchart LR A[AI review on X] --> B[Claude repair pushes Y] B --> C[one AI re-review on Y] C -- "clean or all answered" --> D[supabase-oss approves] C -- "needs a fix / CI red" --> E[maintainer] F[next moved + conflict] --> G["Claude re-resolves same PR<br/>(max 2 resyncs)"] G --> A ``` ### Why On supabase#7158, the AI review saw `39034946` and the repair pushed `b064c720`. Every later `sync-repair` run then logged "Nothing to repair; the AI review did not see this head." until a maintainer approved it. On supabase#7112, `next` moved after approval and the resync conflicted, which left the PR waiting on a person. ### What changed - A resolution is everything after the latest resolve comment (from the first Claude resolve or a resync). Repair rounds count per resolution, using release-bot comments and reviews sorted by time. - After a repair push, `sync-repair` posts a re-review marker, and a separate `actions: write` job dispatches the AI review once. The job that runs Claude never gets that permission. If the dispatch fails, it tags maintainers. - After the re-review, rounds can only reply to findings. Claude declines repeats by pointing at its earlier replies. If a finding needs a fix or CI fails, the PR goes to a maintainer. Nothing is pushed in these rounds. - `fast-forward`: if `next` moved and merging it into an approved `develop`→`next` sync conflicts, it dispatches `sync-branches.yml` with a new `resync_pr` input. That re-runs the resolve, check, fix and publish steps on the same branch and PR. The limit is 3 resolutions. A PR resolved by hand counts as one. If the dispatch fails, or the limit is reached, it falls back to today's "resolve by hand" message. - `resync_pr` only accepts an open same-repository `sync/develop-into-next` → `next` PR. - On a `sync/develop-into-next` PR, the AI review gets `sync-resolution.diff`: each sync merge as `--remerge-diff`, plus the commits made on the sync branch. Both prompts and the adjudicator limit findings to what that resolution introduced, or to code on one side that uses something the other side removed. Previously the review re-checked all of `develop` since the last sync, and most of its findings were dismissed as "not from the merge". - `release-process.md` documents the new rules. ## Linked issue - [x] I'm a Supabase maintainer. ## Checklist - [x] The PR title follows Conventional Commits. - [x] Tests added or updated for the change. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>

Prashansa-K and others added 4 commits October 14, 2026 15:37

supabase-cli-releaser Bot requested a review from a team as a code owner October 14, 2026 16:16

supabase-cli-releaser Bot added the do not merge Approve to apply; do not merge. label Oct 14, 2026

supabase-cli-releaser Bot requested a review from supabase-oss as a code owner October 14, 2026 16:16

github-actions Bot reviewed Oct 14, 2026

View reviewed changes

Comment thread apps/cli/src/commands/inspect/db/inspect-query.integration.test.ts Outdated

Comment thread .github/workflows/ai-review.yml

Comment thread apps/cli/docs/release-process.md

chore(repo): repair the develop-into-next sync

b064c72

avallete approved these changes Oct 15, 2026

View reviewed changes

supabase-cli-releaser Bot merged commit 8e5a4cb into next Oct 15, 2026
59 of 60 checks passed

supabase-cli-releaser Bot deleted the sync/develop-into-next branch October 15, 2026 11:12

avallete mentioned this pull request Oct 16, 2026

ci(release): re-review repaired syncs and re-resolve them when next moves #7205

Merged

3 tasks done

Navigation Menu

Repository navigation

chore(repo): sync develop into next - #7158

chore(repo): sync develop into next#7158
supabase-cli-releaser[bot] merged 6 commits into
nextfrom
sync/develop-into-next

supabase-cli-releaser Bot commented Oct 14, 2026

Uh oh!

supabase-cli-releaser Bot commented Oct 14, 2026

Uh oh!

github-actions Bot left a comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

supabase-cli-releaser Bot commented Oct 14, 2026

Uh oh!

github-actions Bot commented Oct 15, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

supabase-cli-releaser Bot commented Oct 14, 2026

Uh oh!

supabase-cli-releaser Bot commented Oct 14, 2026

Claude resolved the merge of next

Uh oh!

github-actions Bot left a comment

Choose a reason for hiding this comment

🤖 AI Review

Findings

Stats

Uh oh!

Uh oh!

Uh oh!

Uh oh!

supabase-cli-releaser Bot commented Oct 14, 2026

Claude repair round

Uh oh!

github-actions Bot commented Oct 15, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Claude resolved the merge of `next`