chore: production deploy - #6123
Merged
Merged
Conversation
supabase-cli-releaser
Bot
commented
Aug 8, 2026
supabase-cli-releaser
Bot
commented
Contributor
- feat(cli): port shell completion to native TypeScript (CLI-1965) (feat(cli): port shell completion to native TypeScript (CLI-1965) #6083)
- fix(cli): port gen bearer-jwt to native TypeScript (CLI-1961) (fix(cli): port gen bearer-jwt to native TypeScript (CLI-1961) #6064)
- fix(cli): surface serve staging errors (fix(cli): surface serve staging errors #6113)
- fix(cli): port db reset local recreate to native TS (CLI-1955) (fix(cli): port db reset local recreate to native TS (CLI-1955) #6026)
- fix(docker): bump the docker-minor group in /apps/cli-go/pkg/config/templates with 3 updates (fix(docker): bump the docker-minor group in /apps/cli-go/pkg/config/templates with 3 updates #6119)
- chore(ci): bump jdx/mise-action from 4.2.3 to 4.2.4 in the actions-major group (chore(ci): bump jdx/mise-action from 4.2.3 to 4.2.4 in the actions-major group #6120)
- fix(api): accept offset timestamps (fix(api): accept offset timestamps #6117)
## What changed Replaces the Go-binary passthrough for shell tab-completion with two native TypeScript implementations, closing [CLI-1965](https://linear.app/supabase/issue/CLI-1965/port-shell-completion-to-typescript-and-remove-the-complete): 1. **Static scripts** (`legacy/commands/completion/legacy-completion-scripts.ts`) — `supabase completion {bash,zsh,fish,powershell}` now generates the script natively instead of proxying to the Go binary. Cobra v1.10.2's completion scripts turned out to be 100% generic templates that don't bake in the command tree at all (every tab press just shells back out to `supabase __complete`/`__completeNoDesc`), so this is a byte-for-byte transcription of cobra's own `genBashComp`/`genZshComp`/`genFishComp`/`genPowerShellComp` functions, parameterized only by the program name (`"supabase"`) and which hidden command the script calls back into. Pinned against real cobra output via 8 checked-in golden fixtures (`legacy/commands/completion/__fixtures__/`) generated from a real `apps/cli-go` build, so a future accidental edit to the hand-transcribed templates fails CI instead of shipping silently. 2. **Dynamic responder** (`legacy/cli/legacy-complete.ts`, replacing the deleted `complete-passthrough.ts`) — reimplements cobra's `__complete`/`__completeNoDesc` protocol (candidates + a trailing `:<directive>` line) by reflecting over the live `legacyRoot` command tree, rather than hand-authoring a separate Go-shaped shadow model or continuing to shell out to the Go binary. Reflecting over the real tree means completion output self-corrects as the tree's own, separately-tracked content bugs (extra/missing commands, description mismatches) get fixed elsewhere. This removes the completion command family's last dependency on the bundled Go binary — the structural blocker the milestone description calls out, since every `cmd/*.go` command *registration* was load-bearing for tab completion even where the handler itself was already dead. Unblocks the final Go binary trim. ## How the cobra-output-matching question was resolved Delegated protocol research to `go-parity-auditor`, which read cobra v1.10.2 source directly (available in the Go module cache) and cross-checked against `apps/cli-go`. Two categories of cobra behavior turned out to need different treatment: - **Static scripts**: provably independent of the command tree — a pure string-template port, verified byte-identical against a real cobra-built binary (both at generation time and end-to-end through the actual TS CLI subprocess). - **Dynamic protocol**: cobra annotations (`MarkFlagRequired`, `MarkFlagFilename`) that have no equivalent concept anywhere in this TS tree are mirrored as small, explicit, hand-verified lookup tables (matching Go's own hardcoded `cmd/*.go` call sites 1:1) rather than derived generically from TS flag declarations — an earlier attempt to infer "required" from whether a flag was `Flag.optional`-wrapped was a real, confirmed-wrong heuristic (it silently disagreed with cobra on 3 of 6 real required flags, including flags this TS port deliberately made optional at parse time for unrelated validation-ordering reasons) and was replaced with an explicit table during review. ## Review findings and how they were resolved Three independent reviewers (`go-parity-auditor`, `engineer-reviewer`, `architect-reviewer`) ran differential testing against a real `apps/cli-go` build and converged on the same set of real regressions in the first draft of the dynamic responder, all now fixed and covered by new regression tests: - Any global flag before the cursor (e.g. `supabase --debug <TAB>`) was incorrectly suppressing all subcommand-name completion. - A non-root command's own declared global flags (e.g. `seed`'s `--linked`/`--local`) were invisible from anywhere in that command's subtree. - A command's own local flag with the same name as a global flag (e.g. `db diff`'s local `--output`) was offered twice, with contradictory descriptions, instead of the local one shadowing the global one. - `--version` was offered on every command instead of the root only (cobra registers it non-persistently, root-only). - The `--help`/`--version` short-circuit could misfire on a subcommand's own unrelated local flag of the same name (e.g. `migration squash --version <N>`). - The completion-candidate directive was `4` (no-file-completion) too eagerly in cases cobra leaves at `0`. **Deliberately left open / documented, not fixed**: mutually-exclusive flag-group hiding (cobra's `MarkFlagsMutuallyExclusive`, ~45 call sites in `apps/cli-go/cmd/`) is not reproduced — there's no equivalent annotation anywhere in this TS tree to derive it from, and hand-building a ~45-entry shadow table was judged materially higher transcription-error risk than the small, stable tables this PR does maintain (4 file-extension entries, 6 required-flag entries). Deprecated-command/flag filtering is similarly not reproduced, since this TS tree has no "deprecated" concept distinct from "hidden" today. Both are called out in `legacy-complete.ts`'s module doc comment and the completion family's `SIDE_EFFECTS.md`. ## Testing Unit tests for the pure command-path-resolution/flag-collection/classification/formatting logic in `legacy-complete.ts` (against the real `legacyRoot` tree, not a synthetic one) and for `legacy-completion-scripts.ts` (including the golden-fixture byte-exact checks); a small e2e file for each covering the real-subprocess golden paths (`__complete`, `__completeNoDesc`, `completion bash/zsh`); a new shared `legacy-param-introspection.ts` unit test covering the `Param` unwrap logic (hoisted out of `legacy-command-instrumentation.ts`, which had a private, near-identical helper).
## What changed Ports `gen bearer-jwt` (a Phase-0 Go-proxy) to native TypeScript. Go's implementation (`apps/cli-go/internal/gen/bearerjwt/bearerjwt.go`, `cmd/gen.go`) is fully local — no Docker, no network: load config, resolve a signing key from `[auth].signing_keys` (with interactive JWK/kid selection prompts), build claims, sign. Key parity detail: Go's real claims object is a `jwt.MapClaims` (a Go map), so JSON serializes keys **alphabetically**, not insertion order — unlike the pre-existing `legacyGenerateAsymmetricGoJwt` helper (struct-shaped, insertion-order). This required a dedicated map-shaped claims encoder rather than reusing the existing struct-shaped signer as-is; both are now documented and kept deliberately distinct to avoid a future caller mixing them up. Also fixes a validation-order bug in the pre-existing shared `legacy-go-jwt.ts` (extracting a new `legacySignJwtWithJwk`): Go checks key-type/curve first (wrapped in `failed to convert JWK to private key: ...`), then algorithm (unwrapped), and has **no explicit cross-check** between kty and algorithm — a mismatch is only caught when the underlying JWT library itself fails to sign (`failed to sign JWT: key is of invalid type: ...`). Two pre-existing unit tests that asserted the wrong (Go-divergent) behavior are corrected as part of this fix. This is a genuine prerequisite for the port (both commands share this signing path), not new-code-only — flagging explicitly since the commit doesn't otherwise signal that shipped error text for the pre-existing `gen signing-key`-adjacent path changed. Hoisted `apps/cli/src/legacy/commands/gen/gen.signing-keys-config.ts`, shared between `gen bearer-jwt` and the pre-existing `gen signing-key` command (both in the same `gen` family, per this repo's hoist-to-family-root rule). ## Why Part of the M9 "Go removal" milestone. ## Review notes `gen bearer-jwt` mints signed JWTs, so this got an unusually thorough pass: the go-parity-auditor and engineer-reviewer both **built and executed the real Go binary** with probe inputs to verify claims empirically rather than reading source alone. That surfaced (and this PR's follow-up commit fixes) several real correctness/security gaps found only by execution: - A stdin JWK of `null` was silently falling back to a default, non-secret signing key where Go actually refuses. - JWK `alg` wasn't validated against Go's `RS256`/`ES256` allowlist at decode time, letting an `HS256` key reach the signing step instead of being rejected earlier, matching Go. - `--sub ""` (explicitly empty, as opposed to omitted) was incorrectly suppressing `is_anonymous` — Go's own check treats an empty string the same as absent. - `--exp` accepted invalid calendar dates (e.g. Feb 30) that `Date.parse` silently rolled over instead of rejecting, unlike Go's `time.Parse`. - An empty signing-keys array on a real TTY crashed with an unhandled `TypeError` instead of Go's `user aborted`. Also fixed: a missing `Legacy`-prefix convention violation, a misplaced generic JSON-parity helper, sub-second `--valid-for` truncation ordering (verified backwards vs. Go), `--exp` whitespace trimming (Go's pflag trims, this didn't), and a stale test assertion. One architectural suggestion — reusing `legacy-config-validate.ts`'s existing signing-keys helpers instead of the new hoisted module — is deliberately deferred: the go-parity-auditor's own code-executing pass did not find a live behavioral bug from the current shape, and this PR is already large; noting it here so it isn't lost. Fixes CLI-1961
## TL;DR fixes `functions serve` and `supabase start` failing with only `An error occurred in Effect.tryPromise` when an env file read or a runtime staging write fails, which was caused by bare `Effect.tryPromise` call sites whose `UnknownError` wrapper is itself an `Error` so the piped `mapError` guards returned the generic wrapper unchanged.. and is now fixed by converting the five serve call sites to the `try` and `catch` form so the raw filesystem error reaches the user. Also pins the gen types pflag consumption test on a deterministic container inspect failure instead of depending on nothing listening on the local db port... ## ref: - extends: #5904
## Stacks on #6022 This PR is based on `columferry/cli-1954-port-db-start-container-bootstrap-natively-and-remove-the` (#6022), not `develop` — it needs to edit that PR's new `legacy/shared/db-bootstrap/` code before #6022 has merged. GitHub will show #6022's diff here too until that PR merges; once it does, this PR's diff will narrow to just what's described below. ## What changed `supabase db reset`'s local path delegated its container-recreate work to the bundled Go binary via a hidden `db __db-bootstrap --mode recreate` / `--mode await-storage` seam. Ports this to native TS and **deletes the seam entirely** (both files). The issue's premise — that reset "reuses the same create/health/SetupLocalDatabase chain the native start port already implements" — was wrong. Go's `resetDatabase15` (`internal/db/reset/reset.go`) never calls `StartDatabase`; it's a distinctly different composition (no volume-existence probe, no `--from-backup` concept, unconditional setup with the *resolved* migration version instead of `""`, no rollback-on-failure, no `_current_branch` write). This port builds a reset-specific `legacyRecreateLocalDatabase` directly over the same underlying primitives `db start` uses, rather than wrapping `legacyStartDatabase`. Also native now: * The **PG14 recreate branch**: template1 `DROP`/`CREATE DATABASE`, disconnect-clients with Go's exact swallow/surface semantics (a genuine server error surfaces; a node-level socket error or the "database doesn't exist yet" case is swallowed), replication-slot drain with backoff, `InitSchema14`/`ApplyApiPrivileges` (deliberately narrower than the PG15+ `SetupLocalDatabase` — no globals.sql/vault/roles.sql). * **Concurrent satellite-container restart + Kong** `nginx reload` (the Kong-reload behavior was added same-day upstream to fix issue #6016 — this reload **fails the whole command** on error, unlike the existing best-effort Kong reload in `functions serve`, matching Go's own two different policies for the two call sites). * The **storage-container health gate** (`AwaitStorageReady`) — any inspect error maps to "absent" (not just not-found), and an unhealthy-but-present container triggers a hardcoded 30s wait that fails the whole reset on timeout, not just "skip bucket seeding." An empirical probe (real Postgres 14 and 15, using the exact pinned pgconn/pgx versions from `apps/cli-go/go.mod`) settled an open question before implementation: whether Go's single-batch `DROP`/`CREATE DATABASE` sequence is safe against Postgres's "cannot run inside a transaction block" restriction. It is — pgconn's batching semantics never trigger that guard — and the TS port doesn't need to replicate any of that protocol-level behavior: four sequential, unwrapped statement execs reproduce the identical real-world result more simply. Since this is the **third** consumer of `legacy/shared/db-bootstrap/`, also did the directory split that milestone review had been deferring: split it into `legacy/shared/containers/` (generic, cross-service Docker primitives used well beyond Postgres bootstrap) and a narrower `db-bootstrap/` (genuinely Postgres-specific), hoisted the container-CLI boilerplate that had been duplicated across the new remove/restart primitives into the existing `legacy-container-cli.ts`, and extracted the local container-input prelude `db start` and `db reset` were duplicating verbatim (\~130 lines) into a shared `legacyBuildLocalDbContainerInputs`. ## Follow-up: closing the local-reset scope boundary (CLI-2062) The PR originally left one boundary open: `db schema declarative`'s smart-target local-reset prompt and `db schema sync`'s failed-apply recovery reset still shelled out to a **second** `supabase-go` child (`LegacyDeclarativeSeam.execInherit`) to run `db reset --local`, rather than calling the now-native `legacyDbReset` in-process. That subprocess design was itself a parity divergence: because it's a genuinely separate OS process, its own `Execute()`/`PersistentPostRun` fired an *independent* second `cli_command_executed` telemetry event and linked-project-cache write on top of the outer `db schema declarative`/`sync` command's own — something real single-process Go never does (Go's `db_schema_declarative.go` calls `reset.Run` as a plain in-process function call, sharing the one outer `PersistentPostRun`). This is now fixed: * Hoisted the `cfg.isLocal` branch of `legacyDbReset` into a new shared `legacyResetLocalDatabase` (`legacy/shared/db-bootstrap/reset-local-database.ts`) — self-contained, resolving its own services (`LegacyDebugFlag`, `LegacyNetworkIdFlag`, `RuntimeInfo`, `ChildProcessSpawner`, `FileSystem`, `Path`, `LegacyCliConfig`, project-env) rather than taking `LegacyDbResetFlags`/`CliArgs`, so it's callable from any Effect context. `reset.handler.ts`'s own `cfg.isLocal` branch is now a thin wrapper around it, keeping only the version/seed-flags plumbing and the JSON envelope (both specific to the top-level `db reset` command). * Rewired both `db schema declarative`'s smart-target and `db schema sync`'s recovery-reset call sites to call `legacyResetLocalDatabase` directly, dropping the `--network-id` argv-forwarding (the function now resolves `LegacyNetworkIdFlag` itself from the shared context — a closer match to Go's single-process model). The synthesized `` `database reset failed (exit ${code})` `` error message is replaced with a message built from the real typed failure (`` `database reset failed: ${error.message}` ``), since there's no longer a literal subprocess exit code. * Removed `execInherit` entirely — from the `LegacyDeclarativeSeam` interface, its real implementation, and every test mock that stubbed it. * Moved `await-storage-ready.ts` into `legacy/shared/db-bootstrap/` alongside `legacyResetLocalDatabase`, since it now has a second caller. * `generate.layers.ts`/`sync.layers.ts` now expose `legacyDockerRunLayer` directly (previously only nested inside their own `edgeRuntime` composition) — needed for `legacyResetLocalDatabase`'s PG15+ one-shot migrate jobs, the same way `db start`/`db reset`'s own layers do. * Rewrote `generate`/`sync`'s local-reset integration tests to exercise the real native reset (mocked `ChildProcessSpawner` + Docker CLI route, hoisted into a new shared `tests/helpers/legacy-local-reset.ts`) instead of asserting tracked `execInherit` call args, and added explicit assertions that the outer command's telemetry-flush/linked-project-cache-write finalizer fires exactly once even though its body now calls an in-process helper that could, if wrongly implemented, double it. * Verified (grep across `apps/cli-go`) that no Go code becomes dead from removing this TS call site: `internal/db/reset/reset.go` remains fully reachable both via the Go binary's own top-level `db reset` command and via the remaining `--experimental` remote-delegation path in `reset.handler.ts`. ## Why Part of the M9 "Final Cleanup — Go Removal" milestone. Fixes [CLI-1955](https://linear.app/supabase/issue/CLI-1955/port-db-reset-local-recreate-natively-and-remove-the-db-bootstrap) Fixes [CLI-2062](https://linear.app/supabase/issue/CLI-2062)
…emplates with 3 updates (#6119) Bumps the docker-minor group in /apps/cli-go/pkg/config/templates with 3 updates: supabase/realtime, supabase/storage-api and supabase/logflare. Updates `supabase/realtime` from v2.123.5 to v2.124.2 Updates `supabase/storage-api` from v1.68.8 to v1.68.10 Updates `supabase/logflare` from 1.50.0 to 1.50.1 Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore <dependency name> major version` will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself) - `@dependabot ignore <dependency name> minor version` will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself) - `@dependabot ignore <dependency name>` will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself) - `@dependabot unignore <dependency name>` will remove all of the ignore conditions of the specified dependency - `@dependabot unignore <dependency name> <ignore condition>` will remove the ignore condition of the specified dependency and ignore conditions </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
…jor group (#6120) Bumps the actions-major group with 1 update: [jdx/mise-action](https://github.com/jdx/mise-action). Updates `jdx/mise-action` from 4.2.3 to 4.2.4 <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/jdx/mise-action/releases">jdx/mise-action's releases</a>.</em></p> <blockquote> <h2>v4.2.4: Reliable locking detection under forced color</h2> <p>A small patch release that fixes locking-support detection when workflows force colored output.</p> <h2>Fixed</h2> <h3>Detect <code>mise install --locked</code> reliably under forced color (<a href="https://redirect.github.com/jdx/mise-action/pull/580">#580</a> by <a href="https://github.com/scop"><code>@scop</code></a>)</h3> <p>When colored output was forced globally (for example via <code>CLICOLOR_FORCE=1</code>), ANSI escape codes in <code>mise install --help</code> prevented the action from matching <code>--locked</code> in the help text, so locking support was reported as unavailable even on versions of mise that supported it.</p> <p>The help probe now runs with <code>NO_COLOR=1</code> in its environment, which overrides <code>CLICOLOR_FORCE</code> and guarantees plain-text output for the feature detection — regardless of the surrounding workflow's color settings.</p> <p><strong>Full Changelog</strong>: <a href="https://github.com/jdx/mise-action/compare/v4.2.3...v4.2.4">https://github.com/jdx/mise-action/compare/v4.2.3...v4.2.4</a></p> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/jdx/mise-action/blob/main/CHANGELOG.md">jdx/mise-action's changelog</a>.</em></p> <blockquote> <h1>Changelog</h1> <hr /> <h2><a href="https://github.com/jdx/mise-action/compare/v4.2.3..v4.2.4">4.2.4</a> - 2026-07-28</h2> <h3>🐛 Bug Fixes</h3> <ul> <li>locking support detection with force-colored output (<a href="https://redirect.github.com/jdx/mise-action/issues/580">#580</a>) by <a href="https://github.com/scop"><code>@scop</code></a> in <a href="https://redirect.github.com/jdx/mise-action/pull/580">#580</a></li> </ul> <hr /> <h2><a href="https://github.com/jdx/mise-action/compare/v4.2.2..v4.2.3">4.2.3</a> - 2026-07-24</h2> <h3>🐛 Bug Fixes</h3> <ul> <li>export mise path entries to subsequent steps (<a href="https://redirect.github.com/jdx/mise-action/issues/575">#575</a>) by <a href="https://github.com/jdx"><code>@jdx</code></a> in <a href="https://redirect.github.com/jdx/mise-action/pull/575">#575</a></li> </ul> <hr /> <h2><a href="https://github.com/jdx/mise-action/compare/v4.2.1..v4.2.2">4.2.2</a> - 2026-07-24</h2> <h3>🐛 Bug Fixes</h3> <ul> <li><strong>(release-plz)</strong> exit when git-cliff produces no version bump (<a href="https://redirect.github.com/jdx/mise-action/issues/566">#566</a>) by <a href="https://github.com/jdx"><code>@jdx</code></a> in <a href="https://redirect.github.com/jdx/mise-action/pull/566">#566</a></li> <li>ensure <code>tar</code> supports Zstd (<a href="https://redirect.github.com/jdx/mise-action/issues/569">#569</a>) by <a href="https://github.com/JackMyers001"><code>@JackMyers001</code></a> in <a href="https://redirect.github.com/jdx/mise-action/pull/569">#569</a></li> </ul> <h3>📚 Documentation</h3> <ul> <li>update default value of <code>cache_key_prefix</code> (<a href="https://redirect.github.com/jdx/mise-action/issues/570">#570</a>) by <a href="https://github.com/muzimuzhi"><code>@muzimuzhi</code></a> in <a href="https://redirect.github.com/jdx/mise-action/pull/570">#570</a></li> </ul> <h3>New Contributors</h3> <ul> <li><a href="https://github.com/muzimuzhi"><code>@muzimuzhi</code></a> made their first contribution in <a href="https://redirect.github.com/jdx/mise-action/pull/570">#570</a></li> <li><a href="https://github.com/JackMyers001"><code>@JackMyers001</code></a> made their first contribution in <a href="https://redirect.github.com/jdx/mise-action/pull/569">#569</a></li> </ul> <hr /> <h2><a href="https://github.com/jdx/mise-action/compare/v4.2.0..v4.2.1">4.2.1</a> - 2026-07-16</h2> <h3>🐛 Bug Fixes</h3> <ul> <li>verify mise downloads with signed checksums (<a href="https://redirect.github.com/jdx/mise-action/issues/548">#548</a>) by <a href="https://github.com/jdx"><code>@jdx</code></a> in <a href="https://redirect.github.com/jdx/mise-action/pull/548">#548</a></li> <li>exclude PATH from environment export (<a href="https://redirect.github.com/jdx/mise-action/issues/556">#556</a>) by <a href="https://github.com/jdx"><code>@jdx</code></a> in <a href="https://redirect.github.com/jdx/mise-action/pull/556">#556</a></li> </ul> <h3>🔍 Other Changes</h3> <ul> <li>Enable Entire for Codex (<a href="https://redirect.github.com/jdx/mise-action/issues/529">#529</a>) by <a href="https://github.com/jdx"><code>@jdx</code></a> in <a href="https://redirect.github.com/jdx/mise-action/pull/529">#529</a></li> </ul> <h3>⚙️ Miscellaneous Tasks</h3> <ul> <li><strong>(ci)</strong> automate weekly releases (<a href="https://redirect.github.com/jdx/mise-action/issues/557">#557</a>) by <a href="https://github.com/jdx"><code>@jdx</code></a> in <a href="https://redirect.github.com/jdx/mise-action/pull/557">#557</a></li> <li><strong>(release)</strong> skip ai reviews for release prs (<a href="https://redirect.github.com/jdx/mise-action/issues/549">#549</a>) by <a href="https://github.com/jdx"><code>@jdx</code></a> in <a href="https://redirect.github.com/jdx/mise-action/pull/549">#549</a></li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/jdx/mise-action/commit/7e36c90d9ab29c415a2384db3006f3ec8a8cc654"><code>7e36c90</code></a> chore: release v4.2.4 (<a href="https://redirect.github.com/jdx/mise-action/issues/581">#581</a>)</li> <li><a href="https://github.com/jdx/mise-action/commit/493a5fd921e55aa4e741bc218d5f40a239ff7c4b"><code>493a5fd</code></a> chore(deps): update jdx/renovate-config digest to d4f71e1 (<a href="https://redirect.github.com/jdx/mise-action/issues/585">#585</a>)</li> <li><a href="https://github.com/jdx/mise-action/commit/4f7986119ae2063dad066932d4493fbdc9ab0385"><code>4f79861</code></a> chore(deps): update github/codeql-action action to v4.37.2 (<a href="https://redirect.github.com/jdx/mise-action/issues/586">#586</a>)</li> <li><a href="https://github.com/jdx/mise-action/commit/3fb09b2ee659f63d3e04c55772c92ddedb403b84"><code>3fb09b2</code></a> chore(deps): update jdx/pr-closer action to v1.2.0 (<a href="https://redirect.github.com/jdx/mise-action/issues/584">#584</a>)</li> <li><a href="https://github.com/jdx/mise-action/commit/4606f114662cf5bfc6ec17976d9e210506f509af"><code>4606f11</code></a> chore(deps): update jdx/renovate-config digest to aa7a43b (<a href="https://redirect.github.com/jdx/mise-action/issues/582">#582</a>)</li> <li><a href="https://github.com/jdx/mise-action/commit/231917976c407e3d2c4f0198f5b18c5ac5f76d47"><code>2319179</code></a> chore(deps): update actions/checkout action to v7.0.1 (<a href="https://redirect.github.com/jdx/mise-action/issues/583">#583</a>)</li> <li><a href="https://github.com/jdx/mise-action/commit/b4fa3f823ccd9b33c6725ef403907032c5d8adf6"><code>b4fa3f8</code></a> fix: locking support detection with force-colored output (<a href="https://redirect.github.com/jdx/mise-action/issues/580">#580</a>)</li> <li><a href="https://github.com/jdx/mise-action/commit/c3c986141e55f229c6289613b234d38f4d96dbc9"><code>c3c9861</code></a> chore(deps): lock file maintenance (<a href="https://redirect.github.com/jdx/mise-action/issues/579">#579</a>)</li> <li>See full diff in <a href="https://github.com/jdx/mise-action/compare/9e7f7633ff6f6d6048a9418a68d48f288f50eb14...7e36c90d9ab29c415a2384db3006f3ec8a8cc654">compare view</a></li> </ul> </details> <br /> [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore <dependency name> major version` will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself) - `@dependabot ignore <dependency name> minor version` will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself) - `@dependabot ignore <dependency name>` will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself) - `@dependabot unignore <dependency name>` will remove all of the ignore conditions of the specified dependency - `@dependabot unignore <dependency name> <ignore condition>` will remove the ignore condition of the specified dependency and ignore conditions </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
## TL;DR fixes `supabase link` and `supabase branches list` failing against every project, which was caused by the generated response schemas inheriting the OpenAPI spec's Z-anchored `date-time` patterns while the Management API serializes timestamps with a numeric UTC offset, and is now pragmatically fixed by dropping that pattern during code generation so `date-time` strings keep only their `format` annotation. Timestamps are no longer pattern checked at decode time, matching the contract that shipped before the spec added patterns... ## ref: - closes: #6115 - broken by: #6073 - closes CLI-2136
avallete
approved these changes
Aug 8, 2026
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 03880bb153
ℹ️ About Codex in GitHub
Codex has been enabled to automatically 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 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| } | ||
| echo "Go sidecar probe OK" | ||
| fi | ||
| echo "Go sidecar probe OK: ${sidecar}" |
There was a problem hiding this comment.
With this change the Homebrew leg, and the matching Scoop/install-script checks, only verifies that supabase-go exists (and is executable on Unix). If a release package contains an executable but unrunnable sidecar, such as the wrong architecture or a corrupt binary, this workflow still passes because supabase --version exercises only the Bun wrapper and the sidecar is never invoked. Please run the sidecar itself with a harmless command after locating it so the channel verification still catches broken Go-proxied commands before shipping.
Useful? React with 👍 / 👎.
| // against each element's own raw source text — `storedKeys` here is guaranteed | ||
| // free of that gap by the time this runs (CLI-1961 Codex review finding). | ||
| availableKeys = yield* Effect.try({ | ||
| try: () => storedKeys.map(normalizeStoredJwk), |
There was a problem hiding this comment.
When auth.signing_keys_path points at a file whose first entry is unusable, auth.anon_key/auth.service_role_key are unset, and a later entry is valid, this path only normalizes the array and then allows signing with the later key. The Go legacy command reaches flags.LoadConfig first, and config validation generates the default anon/service_role API keys with SigningKeys[0], so the same config fails before the kid prompt; letting the native port succeed means gen bearer-jwt can mint tokens for a local auth config that other Go-backed paths reject. Please validate the first configured key after reading the file and before offering selection.
AGENTS.md reference: apps/cli/AGENTS.md:L13-L15
Useful? React with 👍 / 👎.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.