error creating a release_command machine: failed to launch VM: failed to get manifest

Hey folks, we are just setting up our first app. We are experiencing intermittent failures on deploys where the release_command fails without being able to create a VM. I think it is a race condition between deploy and running the release_command.

Here are the logs (slightly redacted):

```
flyctl deploy -a app --image registry.fly.io/xxx--depot-scope=app --config fly.toml

==> Verifying app config

Validating fly.toml

✓ Configuration is valid

Searching for image ‘registry.fly.io/xxx’ remotely…

image found: img_xxx

Running app release_command: /app/bin/app eval “App.Release.migrate_all()”

:multiply: Failed: error running release_command machine: error creating a release_command machine: failed to launch VM: failed to get manifest registry.fly.io/xxx: request failed: not found [http 404]: {“errors”:[{“code”:“MANIFEST_UNKNOWN”,“message”:“manifest unknown”,“detail”:“unknown tag=deployment-xxx”}]}

Error: release command failed - aborting deployment. error running release_command machine: error creating a release_command machine: failed to launch VM: failed to get manifest registry.fly.io/xxx: request failed: not found [http 404]: {“errors”:[{“code”:“MANIFEST_UNKNOWN”,“message”:“manifest unknown”,“detail”:“unknown tag=deployment-xxx”}]}
```

1 Like

@jtsmills Are you doing a two stage deploy? IE building + pushing your image in one fly deploy command, and then running the actual deploy in another right after?

It does look like it’s hitting a race, where the image hasn’t been pushed to our upstream registry by the time you start the deploy, causing the missing manifest error. We’re making some changes to better support that type of workflow.

There’s a couple options to work around it in the meantime.

  • A retry of the deploy step should succeed after ~1m for normal sized images. Similar with waiting between the initial push and running the deploy.
  • Switching your CI workflow to do a single step fly deploy instead of doing the separate build + push, then deploy steps. This avoids the error I mentioned as it can pull the image from the host’s local registry instead of needing to pull from the upstream
  • You can use --depot=false flag on the build step to use fly-hosted builder. This will also avoid the upstream registry issue. This can be used with the two step deployment flow.

@sam-fly I appreciate that. I am just using the Github integration / deploying on push from the repo.

I’m getting the same error. I tried to deploy an app that has successfully been deployed in the past (gave it a new name and let Fly generate it’s own toml file automatically again) but even after 24hrs and numerous retries it’s still failing with: (app name redacted)

This deployment will:

* create 2 "app" machines


> Launching new machine

No machines in group app, launching a new machine

✖ Failed: error creating a new machine: failed to launch VM: failed to get manifest registry.fly.io/zzzzz-proxy:deployment-8697292e370f8dd3c19fd7e918078db8: request failed: not found [http 404]: {"errors":[{"code":"MANIFEST_UNKNOWN","message":"manifest unknown","detail":"unknown tag=deployment-8697292e370f8dd3c19fd7e918078db8"}]}

Error: error creating a new machine: failed to launch VM: failed to get manifest registry.fly.io/zzzzz-proxy:deployment-8697292e370f8dd3c19fd7e918078db8: request failed: not found [http 404]: {"errors":[{"code":"MANIFEST_UNKNOWN","message":"manifest unknown","detail":"unknown tag=deployment-8697292e370f8dd3c19fd7e918078db8"}]}

(Request ID: 01K76R5MNVS7HHTYQ6CDNXF7XR-iad) (Trace ID: f68457cd2e0cd7d59867ea7590fb4692)

unsuccessful command 'flyctl deploy -a zzzzz-proxy --image registry.fly.io/zzzzz-proxy:deployment-8697292e370f8dd3c19fd7e918078db8 --depot-scope=app '

I’m using the same process (Fly UI) as before.

Hi @jtsmills , I managed to resolve my issue by running the deploy command manually from the command line after the deploy failed.

fly deploy -a zzzzz-proxy -i registry.fly.io/zzzzz-proxy:deployment-6e37778c093ab6337762ba44cf2c9bb2

@geoff-oz did this resolve it going forward? Ideally the deploys on push would be stable going forward :sweat_smile:

1 Like

Same for me, seem like github integration is broken

Additionally: smth weird with env variables, new ones are not being propagated to deploy. old ones still work

1 Like

Same issue here.

Hi folks, we’ve identified what’s causing the issue with the UI deployer. We have a fix in testing and should have it out today.

In the meantime the workaround @geoff-oz mentioned should work to manually deploy the image after it’s been built by the UI deployer:

fly deploy -a <app-name> --image registry.fly.io/<app-name>:<image-tag>

You’ll want to give it a minute or so after the first failure before running that to ensure the image has finished uploading to the registry fully.

Thanks for your patience here while we get this back to normal operation

Hi all, we’ve shipped the fix for the UI deployer and are seeing things flow through as normal.

@liflovs @steveoimd @geoff-oz @jtsmills Please give it another try and let us know if you see any issues deploying via that flow.

Thanks - this seems to have resolved things for me now.

Seems like the UI deployer is still broken, just tried the manual deployment and got my issue fixed

Hi @Jonnie, sorry, we accidentally ended up rolling back this fix while applying some newer updates, causing this bug to resurface. We’ve re-applied this fix to the UI deployer (more permanently this time) so that should be working properly again, sorry for the inconvenience.

I’m just using flyctl (latest version) and I’m still experiencing this race condition. Glad the workaround is available, but this still isn’t fully fixed.