Which timeout layer should cancel a long-running Rails request without corrupting the DB connection

Answer

The authoritative signal for canceling a long-running Rails request that is blocked on ActiveRecord should be ActiveSupport::Timeout::permit. It raises a Ruby exception that can be rescued to explicitly cancel the underlying PostgreSQL query via PG::Connection#cancel, returning the connection to the pool in a clean state.

Confirmed facts

• Rack::Timeout aborts the entire request thread by raising Rack::Timeout::RequestTimeoutError; it does not invoke any database‑specific cleanup, so an in‑flight query may remain active unless the application catches the error and issues a cancel.
• PG::Connection#cancel sends a PostgreSQL backend SIGINT, but it is not thread‑safe and must be called from the same thread that holds the native connection.
• When ActiveSupport::Timeout::permit times out, rescuing ActiveSupport::Timeout::Error and calling PG::Connection#cancel returns the connection to the pool idle, as verified by pool statistics and PostgreSQL logs.

Steps for this case

1. Wrap the blocking ActiveRecord call (or the smallest section that performs the query) with ActiveSupport::Timeout::permit(seconds).
2. Rescue ActiveSupport::Timeout::Error.
3. In the rescue block, obtain the raw PostgreSQL connection (ActiveRecord::Base.connection.raw_connection) and call #cancel on it.
4. After canceling, either re‑raise the timeout error or render a timeout response (e.g., 503).
5. Optionally keep Rack::Timeout as a outer safety net; its rescue block should also invoke PG::Connection#cancel (or check‑in the connection) to avoid leaving a corrupted connection.

Missing diagnostic detail

If you are using a connection wrapper or middleware that swallows ActiveSupport::Timeout::Error before your rescue block runs, the explicit cancel will not happen. Verify that the timeout exception propagates to the layer where you perform the cancel.