Ruby on Rails: Async Query Instrumentation Fix and Auth Generator Polish

Transcript

Hey there, Rails developers! Welcome back to another episode of the Ruby on Rails podcast. I'm your host, and it's March 12th, 2026. Grab your favorite beverage because we've got some really interesting fixes to talk about today that might just solve some mysterious issues you've been having in production.

So picture this scenario - you're using async queries in your Rails app, which is awesome for performance, right? You've got `async_load` and `async_pick` working beautifully with the global thread pool executor. Everything seems great until you notice something weird happening. Some of your requests just... aren't getting their database queries logged properly. The instrumentation is randomly missing, and it's driving you crazy because you can't reproduce it consistently.

Well, if that sounds familiar, rosa just became your hero today. They identified and fixed a really sneaky bug in how Rails handles instrumenters with async queries. Here's what was happening - and this is one of those bugs that really shows how complex modern web applications can be.

When you're using async queries with the global thread pool, Rails has a fallback policy called "caller runs." Basically, if the thread pool gets saturated and all the background threads are busy, the async task falls back to running on your main request thread. Totally reasonable, right?

But here's where it gets tricky. The async execution code was setting up an EventBuffer as the instrumenter and never cleaning up after itself. On a background thread, no big deal - that thread goes away. But when it falls back to your request thread, that stale EventBuffer just sits there, and suddenly your request isn't logging database queries anymore. Rosa described it perfectly - the number of affected requests would start at zero after a deploy, then steadily increase until the next deployment reset everything.

The fix itself is elegantly simple - just restore the previous instrumenter value after the async operation completes. But finding this bug? That takes some serious detective work and deep understanding of Rails' instrumentation system. Rosa submitted this fix in three separate pull requests, and Jean Boussier merged them all, which tells you just how critical this issue was.

Now, switching gears to something completely different but equally important for developer experience - we got a nice quality-of-life improvement for the authentication generator. You know how Rails lets you skip Action Mailer when you're creating a new app? Well, if you did that and then tried to use the authentication generator, you'd get test files that referenced email functionality that didn't exist, and your tests would fail.

Thanks to ssjr, that's now fixed. The generator is smart enough to skip creating tests for password reset functionality when Action Mailer isn't available. It's one of those small fixes that just makes the Rails experience smoother and more predictable.

What I love about both of these changes is they represent Rails at its best - solving real problems that developers face in production. The async query fix addresses performance tooling that's crucial for modern applications, while the authentication generator fix removes those little friction points that can be so frustrating when you're trying to get a new project off the ground.

For today's focus, if you're using async queries in production, definitely make sure you're running the latest Rails version to get this instrumentation fix. And if you've been avoiding the authentication generator because you're not using Action Mailer, give it another try - it should work seamlessly now.

The Rails ecosystem continues to mature in these really thoughtful ways, with contributors like rosa diving deep into complex instrumentation issues and folks like ssjr polishing the developer experience. It's contributions like these that make Rails such a joy to work with.

That's a wrap for today's episode! Keep coding, keep contributing, and remember - every bug fixed makes the framework better for everyone. Until next time, happy developing!