Stop fly launch before deploying when provisioning fails by igor-ladkin · Pull Request #5298 · superfly/flyctl

igor-ladkin · 2026-10-07T10:31:38Z

Change Summary

What and Why:

When Postgres, Managed Postgres, Upstash Redis or Tigris failed to provision, fly launch printed the error, dropped it, deployed the app without the resource and exited 0. Without a terminal or --yes, Tigris fails this way on its terms-of-service check, so coding agents and CI got a successful launch of an app missing its storage.

How:

createDatabases returns the provider errors, joined. A failed Fly Postgres create or attach is returned instead of ending in a red warning.
Launch still writes fly.toml and the rest of the setup, then stops before the deploy and exits 1: "app X was created, but provisioning failed: ", followed by "Fix that and run fly deploy, or run fly deploy now to deploy without it". This applies with or without a terminal.
The fly launch plan postgres|redis|tigris steps return the provider error too; they used to exit 0.
A Managed Postgres cluster still provisioning after 15 minutes is slow, not failed, so that path is unchanged.

TestLaunchStopsBeforeDeployWhenProvisioningFails runs through Launch with Upstash failing; it fails without the fix.

Related to: superfly/ui-ex#5643

Documentation

Fresh Produce
In superfly/docs, or asked for help from docs team
n/a

When Postgres, Managed Postgres, Upstash Redis or Tigris failed to provision, fly launch printed the error, dropped it, deployed the app without the resource and exited 0. Without a terminal or --yes, Tigris fails this way on its terms-of-service check, so coding agents and CI got a successful launch of an app that was missing its storage. createDatabases now returns the provider errors, joined, and a failed Fly Postgres create or attach is returned instead of ending in a red warning. Launch still writes fly.toml and the rest of the setup, then stops before the deploy and exits non-zero, saying the app was created and to fix the failure and run fly deploy, or to run fly deploy now to deploy without the missing resource. Launching again isn't suggested: the app already exists by then. The error is held until just before the deploy because fly.toml is written after the databases, and stopping earlier would leave nothing for fly deploy to read. Plan steps return the provider error as is. A Managed Postgres cluster still provisioning after 15 minutes is slow, not failed, so launch carries on as before.

chatgpt-codex-connector · 2026-10-07T10:32:20Z

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-22T13:15:31.128359Z	`e800313`	Manual request

ℹ️ 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" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

After a failed database or storage provider, launch said to fix the failure and run fly deploy. But fly deploy never provisions anything: after accepting Tigris's terms, for example, the bucket still didn't exist, and the app would deploy without it. Each provider's error now carries the command that adds it later (fly postgres create and attach, fly mpg create and attach, fly redis create, fly storage create), and launch says to run that before fly deploy, or to run fly deploy now to deploy without it.

fly redis create has no app flag and doesn't attach; only launch set REDIS_URL. Without that step the app deploys without its Redis.

Plan steps stop before fly.toml is written, so recovery commands need -a. A Postgres or Managed Postgres failure can come after the cluster exists; point at attaching it before creating another billable one.

With --path or --config, plain `fly deploy` searches the current directory and misses the new config, so name its directory and path. A Redis attach failure comes after the database exists; set REDIS_URL from it before creating another billable one.

A --path or --config with spaces split into extra arguments, and deploy takes one working directory. go-shellquote was already in the graph.

Provisioning can fail after the add-on exists, and storage create refuses an app that already has one.

cmd.exe takes single quotes literally, so the POSIX-quoted paths broke there. Use double quotes on Windows; its paths can't contain them.

A cluster that reached Failed still shows in fly mpg list; destroy it before creating another. fly storage destroy refuses to prompt headless.

A failing init command, Sentry, mount option, config write or secret returned its own error and dropped the provisioning error with its recovery steps; join them instead. Say where to run fly deploy instead of pasting paths into the command: PowerShell expands $ inside double quotes and cmd.exe %, so no quoting is safe in every shell. This drops go-shellquote back to indirect.

The early return dropped what createDatabases had collected, so the recovery steps for a failed Postgres were lost.

The deploy working directory is the build context, so --config deploy/staging.toml pointed the deploy at a folder without the source. Use the launch's working directory and pass the config relative to it.

When the Postgres cluster exists but attaching it failed, the app's database and default user may already exist, so a bare `fly postgres attach` stops on the database prompt or the taken user. Return the exact retry instead, with --yes and a fresh --database-user, and keep the create-or-attach hint for clusters that were never made.

igor-ladkin · 2026-10-22T13:11:50Z

@codex review

chatgpt-codex-connector · 2026-10-22T13:15:29Z

Codex Review: Didn't find any major issues. Keep it up!

Reviewed commit: e800313cd4

ℹ️ 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".

Resolve launch.go with the deferred provisioning error reading --no-create-app through noCreateApp (from #5297), and keep the tests from both sides.