ActiveStorage::AnalyzeJob jobs not running

[olimart]

Hey,

I've got some ActiveStorage::AnalyzeJob jobs not running (in development, haven't checked other envs). They're enqueued to the default queue (automatically by ActiveStorage).

However, other ActiveJob jobs are also enqueued to the default queue but are processed as expected. Since other jobs going through the default queue are processed, ActiveStorage::AnalyzeJob should run as well, right?

This is how I start jobs jobs: bundle exec rake solid_queue:start config file

default: &default
  workers:
    - queues: "critical"
      threads: 10
    - queues: "mailers"
      threads: 5
    - queues: "default"
      threads: 2
    - queues: ["low", "*"]
      threads: 1

development:
  <<: *default
  dispatchers:
    - polling_interval: 5 # default is 1
  workers:
    - polling_interval: 1 # default is 0.1

test:
  <<: *default

production:
  <<: *default

[rosa]

Hey @olimart! Yes, they should run just in the same way if they are in the default queue. However, in your screenshot I see they are indeed running, your first screenshot shows the job in progress, which means it has been picked up by a Solid Queue worker that's running it. It seems the job is hanging for some reason 🤔 To debug it, perhaps you could try to run what the job does manually in your console, as:

ActiveStorage::Blob.find(5).analyze

and see if that gives you a clue. It doesn't seem like a Solid Queue problem from what I gather, though.

[arbythree]

Same problem here. ActiveStorage::Blob.find(NN).analyze runs without incident.

[olimart]

Thanks Rosa. Will take another look but ActiveStorage::Blob.find(5).analyze runs fine. What could happen if, like you mentioned, it is in progress (picked up by Solid Queue) but hanging?

[rosa]

Hmm... Could you copy your database.yml configuration?

[olimart]

Hmm... Could you copy your database.yml configuration?

default: &default
  adapter: postgresql
  encoding: unicode
  pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>

development:
  <<: *default
  database: myapp_development

Along with Puma threads_count = ENV.fetch("RAILS_MAX_THREADS") { 3 }

[olimart]

It's running fine on my desktop (M3), so I guess, something makes it hanging on lower specs (M2 laptop). I'm using PG 16 in case someone notices a pattern. Thanks @rosa

[DustinFisher]

I had this exact same issue come up with my AnalyzeJob which was working fine on my windows desktop machine using ubuntu wsl. On a mac intel laptop I started getting the issue where it went to the in progress jobs, but never completed.

I tracked it back in the logs to this error:

Then found this open issue on rails related to it. https://github.com/rails/rails/issues/38560

Locally in dev if I run this OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES bin/dev I no longer have the issue and eveything runs fine.

[olimart]

Thanks for the tip @DustinFisher will give it a try because run into it again this week 🙏

[elpdev]

Thank you @DustinFisher ! I had the same issue on my M2 mac and this fixed it for me.

[collimarco]

I have the exact same issue.

I see some ActiveStorage::AnalyzeJob in_progress and they never complete (on MacOS, Intel).

The only temporary workaround that works is the env variable suggested by @DustinFisher .

BTW why this issue is closed? It looks like a bug that should be fixed somewhere

[initseis]

This is a known issue in MacOS, @DustinFisher gave the solution. In my case, I use: export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES

[bjacobson26]

export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES fixes the issue for me as well.

Is that a safe permanent solution? seems like a hack.

[ChadMoran]

I'm on a M3 MacBook Pro and also noticed this started happening.

[pjg]

Almost a decade old problem now. Yes, it's safe to set this ENV variable (export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES).

Reference: https://blog.phusion.nl/2017/10/13/why-ruby-app-servers-break-on-macos-high-sierra-and-what-can-be-done-about-it/