IO::EWOULDBLOCKWaitReadable on 1.1.5

[joshleblanc]

I believe this was introduced by this PR: #552

This is running on windows, which I understand is a bit of an oddball situation, so I'm not sure if this is also a problem in linux environments.

{
    "level": "ERROR",
    "time": "2025-05-27T12:52:40.920Z",
    "details": "SolidQueue-1.1.5 Error in thread (0.0ms)  error: \"IO::EWOULDBLOCKWaitReadable A non-blocking socket operation could not be completed immediately. - read would block\"",
    "exception": {
        "msg": "A non-blocking socket operation could not be completed immediately. - read would block",
        "stack_trace": [
            "<internal:io>:63:in 'IO#read_nonblock'",
            "D:/sites/scout-rxmodule/vendor/bundle/ruby/3.4.0/gems/solid_queue-1.1.5/lib/solid_queue/processes/interruptible.rb:22:in 'block in SolidQueue::Processes::Interruptible#interruptible_sleep'",
            "<internal:kernel>:168:in 'Kernel#loop'",
            "D:/sites/scout-rxmodule/vendor/bundle/ruby/3.4.0/gems/solid_queue-1.1.5/lib/solid_queue/processes/interruptible.rb:22:in 'SolidQueue::Processes::Interruptible#interruptible_sleep'",
            "D:/sites/scout-rxmodule/vendor/bundle/ruby/3.4.0/gems/solid_queue-1.1.5/lib/solid_queue/processes/poller.rb:32:in 'block in SolidQueue::Processes::Poller#start_loop'",
            "<internal:kernel>:168:in 'Kernel#loop'",
            "D:/sites/scout-rxmodule/vendor/bundle/ruby/3.4.0/gems/solid_queue-1.1.5/lib/solid_queue/processes/poller.rb:25:in 'SolidQueue::Processes::Poller#start_loop'",
            "D:/sites/scout-rxmodule/vendor/bundle/ruby/3.4.0/gems/solid_queue-1.1.5/lib/solid_queue/processes/poller.rb:21:in 'SolidQueue::Processes::Poller#run'",
            "D:/sites/scout-rxmodule/vendor/bundle/ruby/3.4.0/gems/solid_queue-1.1.5/lib/solid_queue/processes/runnable.rb:13:in 'block in SolidQueue::Processes::Runnable#start'",
            "D:/sites/scout-rxmodule/vendor/bundle/ruby/3.4.0/gems/solid_queue-1.1.5/lib/solid_queue/processes/runnable.rb:82:in 'block in SolidQueue::Processes::Runnable#create_thread'"
        ]
    },
    "location": [
        "D:/sites/scout-rxmodule/vendor/bundle/ruby/3.4.0/gems/activesupport-8.0.2/lib/active_support/log_subscriber.rb:164:in 'ActiveSupport::LogSubscriber#error'",
        "D:/sites/scout-rxmodule/vendor/bundle/ruby/3.4.0/gems/solid_queue-1.1.5/lib/solid_queue/log_subscriber.rb:126:in 'SolidQueue::LogSubscriber#thread_error'",
        "D:/sites/scout-rxmodule/vendor/bundle/ruby/3.4.0/gems/activesupport-8.0.2/lib/active_support/subscriber.rb:138:in 'ActiveSupport::Subscriber#call'"
    ]
}

queue.yml:

default: &default
  dispatchers:
    - polling_interval: 1
      batch_size: 500
  workers:
    - queues: "*"
      threads: 3
      processes: <%= ENV.fetch("JOB_CONCURRENCY", 1) %>
      polling_interval: 0.1

development:
  <<: *default

test:
  <<: *default

production:
  <<: *default

database.yml

default: &default
  adapter: postgresql
  encoding: unicode
  # For details on connection pooling, see Rails configuration guide
  # https://guides.rubyonrails.org/configuring.html#database-pooling
  pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>
  timeout: 5000

production:
  primary:
    <<: *default
    database: <%= ENV['SCOUT_DATABASE'] %>
    username: scout
    password: <%= ENV['SCOUT_DATABASE_PASSWORD'] %>
  cache:
    <<: *default
    adapter: sqlite3
    database: storage/production_cache.sqlite3
    migrations_paths: db/cache_migrate
  cable:
    <<: *default
    adapter: sqlite3
    database: storage/production_cable.sqlite3
    migrations_paths: db/cable_migrate
  queue:
    <<: *default
    adapter: sqlite3
    database: storage/production_queue.sqlite3
    migrations_paths: db/queue_migrate

[rosa]

I believe this was introduced by this PR: #552

Ahh, that PR didn't introduce something new, but rather restored the way this had worked since the beginning. This is not a problem in Linux, only in Windows. I'm afraid I don't have a good solution for this.