Roll back transactions leaked by killed job threads in tests

[rosa]

Since #766, tests that stop in-process workers kill the job threads those workers leak. That kill can interrupt a thread in the middle of a database write, skipping the rollback in the transaction's ensure block while still returning the connection to the pool — with the write transaction still open.

On SQLite that open transaction locks out every other writer. Nothing clears it until the connection pool's reaper flushes the idle connection at its default 300-second idle_timeout, so a single unlucky kill turns into a ~5-minute cascade of SQLite3::BusyException: database is locked errors through whatever tests run next, after which the suite mysteriously heals.

That's been the signature of the recent flaky sqlite legs on CI: dozens of errors, always starting with SolidQueue::JobTest#test_try_to_discard_claimed_job failing in its own teardown ~10 seconds after killing a job thread (it's the only non-transactional caller of the helper), always healing ~300 seconds later. For example, this run and this one, both on main.

The fix: after killing the threads, wait for them to die, then drop all pool connections, which rolls back anything they left open. Transactional tests don't need it — they pin every thread to the test's own connection, so a killed thread can't strand a lock on a connection of its own.

The leaked state and the fix are easy to see in isolation: a thread killed while holding an open transaction leaves the pool with raw_connection.transaction_active? == true and the next writer times out; after disconnect!, the write goes through instantly.

🤖 Generated with Claude Code