$ the-wire · showcase
RAILS KILLS DEADLOCK BUG IN BARE CONNECTIONS, PUSHES RACTOR SAFETY
By RepoJournal · Filed · About Rails · Composed from the cited sources · methodology
A fresh connection trying to check its database version was deadlocking against itself, and Shopify just shipped the fix.
Rails merged a critical fix for NullPool that was causing synchronization deadlocks [1] [2] [3]. The problem: when a bare connection (one using NullPool instead of ConnectionPool) queries server version on startup, it re-enters a Mutex-protected method that wasn't built for re-entrancy. A normal ConnectionPool uses a Monitor, which handles this gracefully, but NullPool's Mutex chokes. This is the kind of subtle bug that burns hours in production. Separately, Active Record is continuing its push toward Ractor safety [4] [5] by freezing and constantizing modules so they can be safely used in Ractorized contexts. This is table-stakes if you're running concurrent Ractors in your app. Documentation got a refresh with this week's TWIR [6] . Nothing earth-shaking here, but the connection deadlock fix is worth deploying immediately if you're using Rails with database connections that spin up fresh.
Action items
- → Pull latest rails/rails main and test fresh connections in your environment rails/rails [immediate]
- → Review your Ractor usage patterns if you're running concurrent code paths rails/rails [plan]
References
- [1] Merge pull request #57506 from Shopify/hm-tnotxonttqlwlvyo ↗ rails/rails
- [2] Fix NullPool#server_version deadlock ↗ rails/rails
- [3] Fix NullPool#server_version deadlock ↗ rails/rails
- [4] Active Record Ractor-safe freezing ↗ rails/rails
- [5] Merge pull request #57475 from Shopify/ar_ractor_freeze ↗ rails/rails
- [6] Add TWIR 29.05.2026 ↗ rails/website