Uh oh!
There was an error while loading. Please reload this page.
feat(cli): add supabase workers list, status and delete - #6263
Conversation
c5f5bb7 to
6710630Compare6710630 to
4745b37Comparec4bae5d to
ae845d0Compareae845d0 to
79874d9CompareThere was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit:ae845d0021
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Supabase CLI previewnpx --yes https://pkg.pr.new/supabase/cli/supabase@5ce85986988d914fdb2feadb2306dfed005bd3e1Preview package for commit |
79874d9 to
460f176CompareThere was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit:460f176452
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
…lly there Addresses the thirteen review findings on #6263. `status` emitted its payload twice in structured mode. `output.success` was called before the format branch and again inside it, and the JSON layer appends each success to stdout — so `JSON.parse(stdout)` failed outright and `stream-json` saw two terminal result events. The bigger theme is these commands stating local facts they had not checked. `legacyDescribeWorker` can always *compute* a source directory, because with no `[workers.<name>]` entry it falls back to the default path — so a worker deployed from somebody else's checkout got a path that looked like fact. `status` reported it as the worker's source, and `delete` claimed to have kept it along with a `config.toml` entry that did not exist, then pointed at a `push` that had no source to deploy. `legacyDescribeWorker` now also answers whether anything local establishes that path, and both commands say only what is true. `list` disagreed with itself and with `push`. The text column read an absent `spec.runtime` on a deployed worker as `dockerfile` — correct, that is what the API's omission means — while the payload fell back to the local config and reported a runtime the deployment had moved off. And the inventory unioned only config entries with API records, so a scaffolded directory with no entry was missing entirely: `list` could answer "No workers found" about a worker a bare `push` would discover and deploy. Both now read the same way, and the deployed-but-unconfigured warning is scoped to rows that are actually deployed. `delete` also prompted when it should not have. `-o json` leaves `output.format` as `text`, so the interactive check passed and the warning and prompt went to the stdout the payload was supposed to own; a machine format is now as non-interactive as a redirected stdout. Its confirmation counted `spec.instances`, the declared target, while calling them "running" — it uses the live tally when the API reports one and says "declared" when it does not, which for a destructive confirmation is the difference that matters. Smaller ones: `-o table` and `-o csv` fell through to the TOML encoder instead of rendering text like every other resource command; project loading, name validation and worker resolution moved inside the finalizers so those failures still flush telemetry; and `status`/`delete` validate against the API's DNS-label rule rather than the local reserved-name rule, since neither writes `[workers.<name>]` and a worker named `root` was visible in `list` but impossible to inspect or remove. The three `SIDE_EFFECTS.md` files now record the telemetry and linked-project writes rather than claiming nothing is written, and the Go-parity framing is out of the docs and the handler comments.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit:7aef5a8106
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit:12ec5199ea
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Uh oh!
There was an error while loading. Please reload this page.
…atus Two from the re-review of #6263, the first a regression the previous round introduced. Making `legacyDescribeWorker` confine the configured source was right for `push`, where that directory is what gets packaged and uploaded. It was wrong for `status` and `delete`, which only *report* on local state — so a `source` that no longer resolves inside the project (an in-project directory that became a symlink, say) failed before either API call and left the remote worker un-deletable until the user edited `config.toml` or moved workdir. Deletion never reads that path. `legacyDescribeWorkerForReporting` degrades instead: an unusable source reads the same as having nothing local, which is exactly what the output needs to say. `push` keeps the strict version. The redeploy advice also fired too readily. A retained `config.toml` entry alone made the "Kept" list non-empty, so `delete` recommended `workers push` for a worker whose source directory was gone — the command it names would have failed. The entry is still reported; the advice now waits on the source actually being there.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit:d2b7f5d359
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit:7c5677e3f3
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit:74cc753c88
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit:c70828770e
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
…lly there Addresses the thirteen review findings on #6263. `status` emitted its payload twice in structured mode. `output.success` was called before the format branch and again inside it, and the JSON layer appends each success to stdout — so `JSON.parse(stdout)` failed outright and `stream-json` saw two terminal result events. The bigger theme is these commands stating local facts they had not checked. `legacyDescribeWorker` can always *compute* a source directory, because with no `[workers.<name>]` entry it falls back to the default path — so a worker deployed from somebody else's checkout got a path that looked like fact. `status` reported it as the worker's source, and `delete` claimed to have kept it along with a `config.toml` entry that did not exist, then pointed at a `push` that had no source to deploy. `legacyDescribeWorker` now also answers whether anything local establishes that path, and both commands say only what is true. `list` disagreed with itself and with `push`. The text column read an absent `spec.runtime` on a deployed worker as `dockerfile` — correct, that is what the API's omission means — while the payload fell back to the local config and reported a runtime the deployment had moved off. And the inventory unioned only config entries with API records, so a scaffolded directory with no entry was missing entirely: `list` could answer "No workers found" about a worker a bare `push` would discover and deploy. Both now read the same way, and the deployed-but-unconfigured warning is scoped to rows that are actually deployed. `delete` also prompted when it should not have. `-o json` leaves `output.format` as `text`, so the interactive check passed and the warning and prompt went to the stdout the payload was supposed to own; a machine format is now as non-interactive as a redirected stdout. Its confirmation counted `spec.instances`, the declared target, while calling them "running" — it uses the live tally when the API reports one and says "declared" when it does not, which for a destructive confirmation is the difference that matters. Smaller ones: `-o table` and `-o csv` fell through to the TOML encoder instead of rendering text like every other resource command; project loading, name validation and worker resolution moved inside the finalizers so those failures still flush telemetry; and `status`/`delete` validate against the API's DNS-label rule rather than the local reserved-name rule, since neither writes `[workers.<name>]` and a worker named `root` was visible in `list` but impossible to inspect or remove. The three `SIDE_EFFECTS.md` files now record the telemetry and linked-project writes rather than claiming nothing is written, and the Go-parity framing is out of the docs and the handler comments.
`collectEntries` stored every symlink as a link entry, which is right for a link inside the packaged tree and wrong for one pointing out of it. The archive is the whole of what the server gets — it runs no install step and has no view of the surrounding repository — so an escaping link arrives dangling: a catalog runtime boots without the dependency, a Dockerfile build fails on the `COPY`, both minutes later with nothing naming the cause. A worker directory that is a pnpm workspace member is the common way in. Its dependencies link to the repository-root store, so every one of them escapes. A worker with `source` pointing at an existing monorepo package is the same case, and that is the use `source` exists for. An escaping link is now refused before the upload. An absolute target that does land back inside the tree is rewritten relative to the link, since a path on this machine resolves to nothing on the other end. Not runtime-specific, so not gated on one: the walk never sees the runtime, and a Dockerfile worker with a symlinked config has the same problem.
`legacyDiscoverWorkerNames` mapped every `readDirectory` failure to `[]` and every per-entry `stat` failure to `None`. A bare `push` on a workers root it cannot list therefore reported "no workers were named, and none were found" — or, when config named some, deployed those and exited 0 having silently skipped every directory-only worker. Absence and unreadable again, one level above the source-directory guards. A missing workers root still reads as nothing: a project may never have scaffolded one, and `[workers.<name>]` entries can name workers that live elsewhere. Every other reason propagates. The per-entry stat keeps skipping a name that vanished between the listing and the stat, and nothing else.
A worker recorded as `runtime = "dockerfile"` deploys its uploaded context as-is, so with no top-level `Dockerfile` the server has nothing to build. That only surfaced as a remote build failure, minutes after the archive had uploaded and a deployment had started, when the CLI was already standing in the directory that answers the question. Only reachable from a recorded runtime. A guessed `dockerfile` always passes, because the classifier picks it by finding this exact file. Classified `invalidConfig` rather than the `provideFlags` its neighbours in this file use: `push` has no runtime flag, so the fix is in `config.toml` or the directory, and the suggestion names both.
This reverts commit 8bac2f2. The guard bought a clearer message for one misconfiguration and cost a runtime-specific branch in a handler that had none, plus a second copy of the `"Dockerfile"` literal already held by the classifier's marker table. The refactor that would have justified it does not exist: markers are evidence for a guess, not requirements. `deno.json` and `package.json` are both optional — `workers new` scaffolds neither — so there is no shared "required source" contract to hoist the check into, and `dockerfile` would stay the lone special case however it were written. Deploying and letting the build report it is the honest cost of not modelling this yet.
kanadgupta
left a comment
There was a problem hiding this comment.
Two blockers and two minor comments below, otherwise LGTM — was able to run these locally with no issues! See below for Claude output (modified/cleaned up a few parts):
This lands the read/delete slice cleanly. The three handlers follow the family's established shape (telemetry finalizers,
-omachine output vs--output-format, the table/details renderers from #6262), errors are typedData.TaggedErrors with actionability, and the integration suites are exactly the scenario-oriented pattern the repo asks for — the delete suite in particular covers the confirmation matrix (typed-name match/mismatch,--yes/SUPABASE_YES, non-interactive refusal,-o jsonrefusal, racing deletes, orphan messaging) with no sleeps or flake bait. Type-the-name confirmation is the right bar for an irreversible delete, and the-o table/csvfall-through fix andsourceExistsonLegacyResolvedWorkerare real improvements over the base.Findings, ranked:
Blocking (both cheap, both on the destructive path):
- Retry suggestions drop an explicit
--project-ref(delete.handler.ts:97 and :126; also status:136) — copy-pasting the suggestedworkers delete <name> --yesfrom a checkout linked to a different project deletes a same-named worker in the wrong project, unprompted. Replied on Codex's open thread.-o envis rejected only after the DELETE (delete.handler.ts:133) —legacyRejectWorkersEnvOutputexists for exactly this andpushalready calls it;workers delete api --yes -o envcurrently deletes the worker, then exits non-zero with no payload.list/statusshould adopt the same up-front call. Replied on the existing threads.Questions:
- Should
delete --yestreat an already-absent worker as success rather than failing withWorkerNotDeployedError? The API layer deliberately treats a DELETE 404 as done, but the pre-flight GET turns idempotent scripted teardown into a non-zero exit. Either answer is defensible; worth deciding on purpose.Recommendation: request changes — solely for the two delete-path items above; both are a few lines, and everything else is in good shape.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit:c58c9b859f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Uh oh!
There was an error while loading. Please reload this page.
The refusal lived in the emitter, which on `delete` runs after the DELETE: `workers delete api --yes -o env` removed the worker and only then exited non-zero with no payload, which a script reads as a failed delete. `legacyRejectWorkersEnvOutput` already exists for this ordering problem and `push` calls it up front; `list`, `status` and `delete` now do the same.
A suggested retry is copy-pasted verbatim, so one that drops an explicit `--project-ref` re-resolves to whatever the checkout is linked to. On `workers delete` the suggestion carries `--yes`, so the copy-paste deletes a same-named worker in a project the user never named, with no prompt. `legacyWorkersProjectRefSuffix` appends the ref only when the flag supplied it — when the link did, re-stating it is noise.
`deleteWorker` already treats a DELETE 404 as done — "a delete that races another one is still a delete that happened" — but the pre-flight GET contradicted that, so a teardown script run twice exited non-zero the second time for a worker in exactly the state it asked for. Under `--yes` an already-absent worker is now a success that skips the DELETE and emits the usual payload. Interactive runs keep the error: somebody typed the command and wants to hear the worker was not there.
The `not deployed` error inherited `status`'s suggestion verbatim, so `delete` advised deploying the worker the user was trying to remove. Somebody deleting "api" and hearing "nothing is deployed" wants to see what *is* deployed.
The emitter's last branch is TOML, so the denylist made every `-o` value it had not heard of serialise as TOML — the next format the global flag learns would silently emit TOML from every workers command until somebody remembered to exclude it. An allowlist keeps today's behaviour identical and makes an unrecognised value fall through to text rendering, which is the direction the `table`/`csv` fix already chose. `env` stays in the set so it reaches the refusal.
A review finding claimed `-o toml` throws on the optional fields these payloads leave undefined. It does not — smol-toml, the YAML encoder and the JSON encoder all omit an undefined-valued key, nested ones included. These two tests record that, so the claim does not have to be re-derived.
`output.interactive` only tracks stdout, so with a TTY stdout and a piped stdin `printf 'api\n' | supabase workers delete api` fed the pipe straight into the confirmation prompt and deleted without `--yes` — a confirmation the user never typed. The prompt now also requires `tty.stdinIsTty`, the same pair `projects delete` guards its own prompt with. The workers test helper gained a `stdinIsTty` option, defaulting to `interactive` so existing prompt scenarios are unchanged.
Two corrections to the details block: - The readiness fraction read its numerator from the instance snapshot and its denominator from `spec.instances`. Mid-scale those disagree, rendering impossible fractions like `3/1 ready`; both now come from the tally. - A worker whose last build failed was told to fix it and push again even while `deleting` was true. Deletion is asynchronous, so that push races the tombstone or resurrects the worker being removed.
Both commands act on the remote worker and consult the project only for the optional source detail, but the load was a hard prerequisite — so an unrelated parse error in `supabase/config.toml` stranded a deployed worker even when `--project-ref` named the project explicitly and nothing local was going to be touched. `legacyLoadWorkersProjectForReporting` degrades an unloadable config to a project with no `[workers.*]` entries, the same shape `legacyDescribeWorkerForReporting` already uses for an unusable source path. `list` and `push` keep the strict load: their output *is* the local inventory. Also drops an `as WorkerNotDeployedError` cast in the status suite for the `instanceof` narrowing the workspace rules ask for.
Two places stated something about local files that was not true: - `status` printed a Source row whenever a `[workers.<name>]` entry existed, including when the configured `source` could not be resolved and the default directory had stood in for it — naming a path the entry does not. `LegacyResolvedWorker` gained `sourceResolved` to tell the stand-in apart. - `list` told every unconfigured deployed worker that a push "would have to guess the runtime". For one with nothing local at all that is the wrong prerequisite: `deployOneWorker` checks the source directory first and fails with `WorkerSourceMissingError`. Those are now split, and the remote-only case is told to scaffold or restore the source.
The API grants the two endpoints separately — `edge_functions:read` for the `GET`, `edge_functions:write` for the `DELETE` — so a credential holding only write got a 403 on the pre-flight lookup and never reached the delete it was entitled to perform. That lookup is a courtesy: it supplies the instance tally the confirmation quotes and the already-gone verdict. A refused read now leaves the worker unknown rather than absent — the prompt still asks for the name but quotes no count, and the DELETE goes ahead. Only a real 404 still means there was nothing to delete. Also records `instances.live` in the delete side-effects response column, which the confirmation has always preferred over `spec.instances`.
The checklists drive E2E coverage, so the gaps understated what the commands actually touch: - `config.json` is preferred over `config.toml` by the loader; only `push` recorded that. - The workers root is enumerated and each child stat'd by `list`; the source path is canonicalised and stat'd by `status` and `delete`. - Project-ref resolution reads `SUPABASE_PROJECT_ID` and `supabase/.temp/project-ref`, and can call `GET /v1/projects` for the interactive picker. - The credential file is read when the env var is unset and the keyring is empty. - None of the three documented their stdout/stderr contract; each now has the template's Output Formats section.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit:eb94457028
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
The list checklist claimed `[workers] root` could redirect the enumerated directory. It cannot: `WorkersSection` carries only `workers`, `readWorkersSection` reads every table under `[workers]` as a worker name, and `workersDir` is hard-coded to `<workdir>/supabase/workers`. Recording a configurable root would have pointed E2E coverage at behaviour the command does not have. The same false premise sat in a `status` test comment, which claimed `root` is unusable as a worker name locally because `[workers] root` occupies the key. There is no such key and no reserved name.
Summary
Completes the command family with the three remaining subcommands:
workers list— this project's workers.workers status— one worker in detail.workers delete— remove a worker, with confirmation.All three reuse the API client and output helpers introduced in #6262, so this is
the smallest layer of the stack.
Stack 4 of 4, on top of
workers push(#6262).Linked issue
FUNC-753 (Linear). Supabase maintainer, exempt from the
open-for-contributionflow.Checklist