BourreauWorkers (for tasks) and BackgroundActivityWorkers (for BACs) all run a regular, infinite main loop to query the database for something to do.
When the DB connection goes down, however, that main query crashes and the worker quits. That's what we actually want. But the logs that the worker maintains contain a full stack trace of the event, which I think is unnecessary.
The stack trace looks like this:
2025-09-01 10:31:50 FATAL BackgroundActivityWorker-2538218: Exception raised: ActiveRecord::StatementInvalid : Mysql2::Error::ConnectionError: Lost connection to server during query: SELECT `background_activities`.* FROM `background_activities` WHERE `background_activities`.`remote_resource_id` = 107 AND `background_activities`.`status` = 'Scheduled' AND `background_activities`.`handler_lock` IS NULL AND (start_at < '2025-09-01 14:15:41.338741')
2025-09-01 10:31:50 FATAL BackgroundActivityWorker-2538218: /home/cbrain01/.rvm/gems/ruby-2.7.2@nibi/gems/mysql2-0.5.6/lib/mysql2/client.rb:151:in `_query'
2025-09-01 10:31:50 FATAL BackgroundActivityWorker-2538218: /home/cbrain01/.rvm/gems/ruby-2.7.2@nibi/gems/mysql2-0.5.6/lib/mysql2/client.rb:151:in `block in query'
(etc etc)
I think in the main loop we should trap exceptions of type ActiveRecord::StatementInvalid and log a simple FATAL error message about the disconnection. Then of course, the worker should exit peacefully.
BourreauWorkers (for tasks) and BackgroundActivityWorkers (for BACs) all run a regular, infinite main loop to query the database for something to do.
When the DB connection goes down, however, that main query crashes and the worker quits. That's what we actually want. But the logs that the worker maintains contain a full stack trace of the event, which I think is unnecessary.
The stack trace looks like this:
I think in the main loop we should trap exceptions of type
ActiveRecord::StatementInvalidand log a simple FATAL error message about the disconnection. Then of course, the worker should exit peacefully.