feat(stack): prepare slim resources on demand - #6250
Conversation
|
Automated review triage is complete for this batch. Fixed:
Deliberately deferred:
This is the final automated-fix pass for this PR. The remaining items need human product and architecture review rather than another mechanical review loop. |
|
Final automated-review disposition:
This is the final automated-review pass. The remaining recorded deferrals are unchanged; the PR is ready for human review. |
Supabase CLI previewnpx --yes https://pkg.pr.new/supabase/cli/supabase@cfe200427d7b32e943d87d15863058f640385660Preview package for commit |
![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
cli/packages/stack/src/BinaryResolver.ts
Lines 726 to 731 in 05b8067
Avoid deleting a concurrently published cache
When two processes repair the same incomplete cache, both can fail the initial rename and observe the destination as incomplete; if one publishes after the other's check, this unconditional removal deletes the newly complete directory that the winner may already have returned to a starting service. That produces intermittent missing executables despite successful resolution. Use a cross-process lock or a replacement protocol that cannot remove a destination after another contender has published it.
ℹ️ 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".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e8372805bf
ℹ️ 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".
|
Addressed the cache-publication finding from review 4976855133 in 4d31f6c. Invalid-destination repair now takes an atomic cross-process publication claim and revalidates the destination under that claim before removing anything. Private staging and the uncontended atomic-rename path remain unchanged. A deterministic resolver integration scenario covers a stale repairer observing another resolver publish and verifies that the winner is reused rather than replaced. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 4d31f6c4aa
ℹ️ 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".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f5f1603bf1
ℹ️ 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".
![depthfirst-app[bot]](https://avatars.githubusercontent.com/in/1021002?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: 066c466b66
ℹ️ 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".
There was a problem hiding this comment.
💡 Codex Review
cli/packages/stack/src/services/postgres-init.ts
Lines 113 to 116 in ac4cb18
Use a completion marker after all native migrations
If initial native initialization is interrupted or a migration fails after initial-schema.sql creates the authenticator role, the next start takes this branch and skips every remaining init script and migration. The one-shot can then report success against a partially initialized database, leaving later services to fail on missing schema objects until the data directory is deleted; detect completion using a marker written only after the entire migration sequence succeeds rather than an early-created role.
cli/packages/stack/src/services/postgres-init.ts
Lines 92 to 93 in ac4cb18
Quote native migration executable and file paths
When cacheRoot contains whitespace, the generated shell expands this composite psql command as multiple words, so native Postgres initialization tries to execute only the path prefix and fails. The later init_flags and migrate_flags strings also append unquoted SQL paths, causing the same splitting for every -f argument; invoke the quoted executable separately and preserve migration paths as shell-safe arguments or arrays.
ℹ️ 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".
…3-stack-prepare-slim-resources-safely-on-demand-or-upfront # Conflicts: # packages/stack/src/Stack.unit.test.ts
|
Addressed the two review-body findings in cbc66a7.
The two inline findings from this review were already fixed and resolved in 59a2305. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: cbc66a7a32
ℹ️ 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".
…3-stack-prepare-slim-resources-safely-on-demand-or-upfront
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: cfe200427d
ℹ️ 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".
| onSuccess: (value) => | ||
| Effect.andThen(markDownloadFinished(), Deferred.succeed(deferred, value)), |
There was a problem hiding this comment.
When the caller that created this single-flight is interrupted or disposes its stack during a download, its prepareEvents queue is shut down while the coordinated fiber continues in the longer-lived layer scope. If another stack is awaiting the same inFlight entry, markDownloadFinished() then offers to that closed queue and is interrupted before Deferred.succeed runs; the ensuring removes the map entry, but the second stack's deferred is never completed, so its lifecycle request hangs indefinitely. Complete the shared deferred before attempting the caller-owned notification, or make that notification best-effort.
AGENTS.md reference: AGENTS.md:L62-L66
Useful? React with 👍 / 👎.
| servicePolicies.auth !== "off" && config.auth !== false | ||
| ? (config.auth ?? undefined) | ||
| : undefined; | ||
| const edgeRuntimeEnabled = servicePolicies["edge-runtime"] !== "off"; |
There was a problem hiding this comment.
When runtime auto-selection falls back to native mode and the caller supplies functions without an explicit edgeRuntime config, this marks Edge Runtime off while resolveFunctionsConfig still accepts and stores the bundle. The stack then starts successfully without an Edge Runtime service, so the explicit functions are silently unavailable; this also occurs when servicePolicies["edge-runtime"] is off. The public functions golden path supplies only functions and relies on Edge Runtime being enabled, so reject this incompatible configuration instead of discarding the requested workload.
Useful? React with 👍 / 👎.
1 participant
Summary
Context
This keeps resource preparation, runtime selection, and activation inside @supabase/stack, with the CLI remaining a thin consumer. An omitted mode selects Docker when Docker or Podman is usable and otherwise selects native mode. Explicit native or Docker choices are strict, preparation never falls back to the other mode, and managed stacks pin their persisted selection once claimed, including after a failed startup. Changing modes requires deleting and recreating the stack and its managed data.
Stack creation stays side-effect free beyond runtime detection and port reservation. Eager resources are prepared at startup, while lazy resources are prepared through the same activation path used by proxy and programmatic callers. Concurrent work is coalesced, disposal completes waiters with typed failures before cancellation, and cached paths cannot start services after disposal begins. Download completion restores prior public state atomically without overwriting a newer lifecycle transition. Concurrent Functions and Edge Runtime reloads preserve each committed state.
Docker and Podman remain exclusive runtime selections. Vector consumes the selected runtime socket when one is usable (readable and writable); a socket-less host uses internal Vector logs instead of crash-looping the service, and Podman never implicitly adopts the Docker default socket.
The catalog uses the frozen service versions, including Postgres 17.6.1.163, and preserves exact published container tags. The canonical Postgres image starts through its published non-root entrypoint and database bootstrap is modeled as an observable one-shot dependency before consumers become ready. Docker-only services remain container-backed until they have a concrete native runtime consumer.