In my use case, I need to create and delete apps all the time. When i create a new app I want to also add support for sentry to it. That is easily done with fly ext sentry create --app <app_name>.
But, if I destroy the app and the sentry integration with fly apps destroy <app_name> and fly ext sentry destroy --app <app_name> and try to re-create the app with the same name, the sentry creation command will fail with the following error:
Error: input:3:2: createAddOn Validation failed: Provider service has already been taken
But the support says it added a fix for it but it clearly it doesn’t work or it was reverted afterwards.
So, I humbly ask for a feedback about this issue, is there no fix for this? Should I expect a fix for it any time soon or is it just that re-creating apps with the same name are just broken/not supported?
Hm, that’s a bit of a rubbish bug. However, what does fly ext sentry create do that you can’t do in a Dockerfile? I assume it is just a wrapper around installing the Sentry agent and injecting some secrets, and if so, could you just do those things yourself?
I don’t think that is the case, AFAIK, what that command do is create the sentry project for your app in Sentry and sets the SENTRY_DSN secret in your app secrets.
The issue here seems to be that Fly doesn’t actually delete the project in Sentry when you call fly ext sentry destroy it just unset the secret or something like that.
So, next time you try to call it to add to your app, it will fail because a project with that name already exists in Sentry.
What I think it should do is either delete the Sentry project too, or, at least give the user the option to define the sentry project name during fly ext sentry create , something like --project-name <sentry_project_name>. That way, the user can always use a unique name for the Sentry project as a workaround.
The issue here seems to be that Fly doesn’t actually delete the project in Sentry when you call fly ext sentry destroy it just unset the secret or something like that.
Yes, so stop using fly ext sentry.
Are they not things you can do yourself? I didn’t include in my mini list an API call to Sentry, to create the sub-account, but I should think that is possible too.
As an alternative, if you really want to workaround this bug, rather than avoiding it entirely, you could add a numeric suffix to your app name, and then fetch the latest app name from Fly using their API. Thus you’d be able to supply a completely fresh name for each app creation to the Sentry command.
But just “stop using X” doesn’t seem like a good answer, should I expect that any flyctl command is broken and I should just not use it if it doesn’t work for whatever reason?
I think your suggestion is a good workaround and probably will work (I will try it out now), but I do still hope to get some feedback from Fly.io on making that feature work, specially considering that a lot of people had the same issue for years without any feedback from them.
I don’t work for Fly. I think the team are super-talented and kindly towards customers. Nevertheless, 95% of suggestions here are backlogged; that’s just the nature of product development. I think it would be great to hear from Fly on this topic, but fixing something oneself is nearly always the quickest route.
I still use the fly ext sentry commands to create and destroy (so it still has all the integrations with fly.io), but, after calling fly ext sentry destroy I call the api from Sentry to delete the project, in courl it would be this:
