Failure due to unhealthy allocations (active record migration?)

Hi guys,

I get the following error when I try to deploy a rails app. I’m not even sure what the error is. Could someone please help? I tried cleaning up some of the migration files I had (e.g. ones where I had dropped a table and/ore removed columns) but it doesn’t seem to help.

The actual error is:
Failed due to unhealthy allocations - no stable job version to auto revert to and deploying as v5

When I run rails normally (e.g. rails s), I get this message. I’ve ignored it until now because it didn’t really affect the app but could fly fail because of this? If so, how do I fix this?

.rbenv/versions/2.6.7/lib/ruby/gems/2.6.0/gems/pry-byebug-3.8.0/lib/pry-byebug/control_d_handler.rb:5: warning: control_d_handler's arity of 2 parameters was deprecated (eval_string, pry_instance). Now it gets passed just 1 parameter (pry_instance)

This looks like an issue running your migrations. Check the full output of the logs for the complete error message.

That screenshot was the full output. It doesn’t exactly say what the error is…

Looking at your app’s logs, the error message is:

PG::DuplicateColumn: ERROR:  column "content" of relation "track_options" already exists	

Sorry, yeah, I noticed that and fixed it. The app’s been deployed but now when I try to run rails db:seed within fly console, I get:

ERROR: null value in column "user_id" of relation "tracks" violates not-null constraint

I tried changing the user_id on the schema of the tracks table from null:false to null:true. But it doesn’t fix it.

btw, how did you know that my app’s logs mentioned this? It wasn’t in the screenshot I shared…

I’m an employee of fly.io, so I was able to find your user account and app in our system, and look at the app logs.

Cool. Do you know how I should go about fixing the seeding issue? There’s no problem when I run rails db:seed in my local env…

How did you do that? If you edited db/schema.rb directly that won’t work, the database itself has a schema and that needs to be updated. Generally you would update that schema by creating a migration.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.