Upgrading to 1.1.1 makes recurring job to fail

[max-chem-eng]

Ruby: 3.4.1
Rails: 8.0.1
solid_queue running as a plug_in
This simple recurring job fails:

production:
  periodic_cleanup:
    class: CloseTripsJob
    queue: background
    schedule: every hour

with this error:

10:48:03 web.1  | Invalid recurring tasks:
10:48:03 web.1  | - production: Schedule is not a supported recurring schedule, either command or class_name must be present
10:48:03 web.1  | Exiting...
10:48:07 web.1  | Detected Solid Queue has gone away, stopping Puma...

EDIT: it only fails if the only environment declared is production and trying to run the app in development

[rosa]

🤔 it seems that CloseTripsJob might not be defined? Does that exist?

[jnstq]

Same for me, I had remove the environment in order to boot solid queue.

See if this works:

periodic_cleanup:
  class: CloseTripsJob
  queue: background
  schedule: every hour

[max-chem-eng]

🤔 it seems that CloseTripsJob might not be defined? Does that exist?

it started failing when upgraded to 1.1.1, 1.1.0 works fine

[RemoteCTO]

Same issue for me.
On examining Mission Control, my list of workers was empty. Reverting to 1.1.0 and things are back to normal.

[rosa]

To be clear, with 1.1.0, invalid recurring tasks would be silently ignored, leading to confusing situations where people didn't know why they weren't being run. With 1.1.1, these fail. If reverting to 1.1.0 works, fine, it might simply mean that they're ignored.

[rosa]

@jnstq nothing has changed regarding the environment keys in recurring.yml. If you remove it and that works, it might be that the recurring tasks aren't being loaded at all.

[rosa]

Oh, @max-chem-eng, I just realised that the recurring task failing for you is production 😕 That's very odd. Is this failing in development only?

[max-chem-eng]

To be clear, with 1.1.0, invalid recurring tasks would be silently ignored, leading to confusing situations where people didn't know why they weren't being run. With 1.1.1, these fail. If reverting to 1.1.0 works, fine, it might simply mean that they're ignored.

thanks for your input
with version 1.1.0 I can confirm that the recurring task is working just fine, if I update it to:

development:
  periodic_cleanup:
    class: CloseTripsJob
    queue: background
    schedule: every second

I see it running without issues

If I update it to 1.1.1 it fails with the mentioned error:

Invalid recurring tasks:
- production: Schedule is not a supported recurring schedule, either command or class_name must be present

regardless I run it as plug in or in its own terminal

EDIT: it only fails if the only environment declared is production and trying to run the app in development

[RemoteCTO]

In my case it's working fine in development, but the workers are failing in production once updating to 1.1.1.

I reverted and then upgraded again in prod and still getting the same issue.
Currently digging into why the workers are failing to boot on prod.

[RemoteCTO]

Right ok, I've dug into the failure trying to manually kick off bin/jobs in a container on prod; in my case the error was:

> Solid Queue is configured to use 3 threads but the database connection pool is 2. Increase it in `config/database.yml

Increasing the RAILS_MAX_THREADS has brought prod back up to life.

I can see this check was added to 1.1.1, so was the issue in my case:

solid_queue/lib/solid_queue/configuration.rb

Lines 78 to 83 in e0921d2

	def ensure_correctly_sized_thread_pool
	if (db_pool_size = SolidQueue::Record.connection_pool&.size) && db_pool_size < estimated_number_of_threads
	errors.add(:base, "Solid Queue is configured to use #{estimated_number_of_threads} threads but the " +
	"database connection pool is #{db_pool_size}. Increase it in `config/database.yml`")
	end
	end

[max-chem-eng]

thanks!

[rosa]

Ok, just released version 1.1.2 with a fix for the recurring configuration when not all environments are defined. Sorry about that!

[dgmora]

Hello, after updating I noticed the following raises an error:

development: 
# nothing

/Users/david/.local/share/mise/installs/ruby/3.4.0/lib/ruby/gems/3.4.0+1/gems/solid_queue-1.1.2/lib/solid_queue/configuration.rb:144:in 'block in SolidQueue::Configuration#recurring_tasks': undefined method 'has_key?' for nil (NoMethodError)

          RecurringTask.from_configuration(id, **options) if options.has_key?(:schedule)
                                                                    ^^^^^^^^^
        from /Users/david/.local/share/mise/installs/ruby/3.4.0/lib/ruby/gems/3.4.0+1/gems/solid_queue-1.1.2/lib/solid_queue/configuration.rb:143:in 'Hash#each'
        from /Users/david/.local/share/mise/installs/ruby/3.4.0/lib/ruby/gems/3.4.0+1/gems/solid_queue-1.1.2/lib/solid_queue/configuration.rb:143:in 'Enumerable#map'
        from /Users/david/.local/share/mise/installs/ruby/3.4.0/lib/ruby/gems/3.4.0+1/gems/solid_queue-1.1.2/lib/solid_queue/configuration.rb:143:in 'SolidQueue::Configuration#recurring_tasks'

Removing development: works around this, but if the yaml is valid then it probably should not fail

[rosa]

Oops, yes! I'll fix that. Agh. So sorry @dgmora!

[rosa]

Fixed in #475