From 1e4d8d43577e7d0a06999ec0cff3ec35bb0739ce Mon Sep 17 00:00:00 2001 From: Lucas Carlson Date: Thu, 1 Oct 2026 09:00:23 -0700 Subject: [PATCH] test: install the busy handler the test assumes The unrestorable busy wait test assumed that its connection already had a Ruby busy handler, which PRAGMA busy_timeout reads as 0. Rails 7.2 and later install that handler on each new connection, and an earlier sync call installs it too. A new Rails 7.1 connection instead uses SQLite's own busy_timeout, which PRAGMA reads as 5000. When the test ran first on Rails 7.1, the adapter correctly took the restorable path and put back SQLite's own wait. That wait holds the Ruby VM lock, so the releaser thread could not release the write lock, and the write raised SQLite3::BusyException after 5 s. Seed 11785 failed every time; CI run 35874660739 failed the same way. Install the handler in the test and assert that PRAGMA reads 0, so the test checks the unrestorable path on every Rails version and order. --- test/integration/synchronous_invocation_test.rb | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/test/integration/synchronous_invocation_test.rb b/test/integration/synchronous_invocation_test.rb index 875c599..1f88711 100644 --- a/test/integration/synchronous_invocation_test.rb +++ b/test/integration/synchronous_invocation_test.rb @@ -588,7 +588,10 @@ def wait(timeout:) database_adapter = SolidObjects.database_adapter database_adapter.define_singleton_method(:configured_busy_handler_timeout) { |_connection| nil } - SolidObjects::Record.connection_pool.with_connection do + SolidObjects::Record.connection_pool.with_connection do |connection| + connection.raw_connection.busy_handler_timeout = configured_sqlite_busy_handler_timeout + assert_equal 0, connection.select_value("PRAGMA busy_timeout").to_i + CounterActor.ref("unrestorable").increment assert_nothing_raised do