Description
app/models/health_check.rb line 156 catches Exception (the base class of all Ruby exceptions):
rescue Exception => e
retry_times -= 1
retry unless retry_times == 0
Exception is the superclass of SignalException, SystemExit, Interrupt, NoMemoryError, and ScriptError. Catching these prevents:
Ctrl+C (Interrupt) from stopping the server process gracefully.
SIGTERM (SystemExit) from stopping the process—critical for deployment and container shutdown.
- Out-of-memory conditions from propagating to the process manager.
Additionally, the retry logic retries SignalException 3 times before finally re-raising... actually it never re-raises: after 3 retries it falls through to attrs[:status] = 'failure', swallowing the signal entirely.
Suggested approach
Catch only application-level errors:
rescue StandardError => e
retry_times -= 1
retry unless retry_times == 0
# ...
end
Also consider rescuing specific known exceptions (Capybara::Error, Net::ReadTimeout, etc.) and handling them differently (retry on timeout, fail fast on element-not-found).
Effort: small
Description
app/models/health_check.rbline 156 catchesException(the base class of all Ruby exceptions):Exceptionis the superclass ofSignalException,SystemExit,Interrupt,NoMemoryError, andScriptError. Catching these prevents:Ctrl+C(Interrupt) from stopping the server process gracefully.SIGTERM(SystemExit) from stopping the process—critical for deployment and container shutdown.Additionally, the retry logic retries
SignalException3 times before finally re-raising... actually it never re-raises: after 3 retries it falls through toattrs[:status] = 'failure', swallowing the signal entirely.Suggested approach
Catch only application-level errors:
Also consider rescuing specific known exceptions (Capybara::Error, Net::ReadTimeout, etc.) and handling them differently (retry on timeout, fail fast on element-not-found).
Effort: small