Elliot's Microblogging

Elliot · May 14, 2026, 11:19pm

I submitted a patch to Ruby on Rails

github.com/rails/rails

Prevent development welcome route from duplicating on route reload (#57367)

main ← curi:fix-development-welcome-route-reload-growth

opened 11:16PM - 14 May 26 UTC

curi

+21 -2

### Motivation / Background Rails registers its internal development welcome ro…ute from `routes_reloader.run_after_load_paths`. That hook currently calls `app.routes.append` on each route reload. `RouteSet#append` stores append blocks persistently, while route reloads clear and finalize the realized routes. As a result, repeated `reload_routes!` calls in development add another internal `GET /` welcome route each time. ### Detail Register the internal welcome route append block only once per application boot, while preserving the existing `append` behavior and route ordering. This keeps app-appended root routes taking precedence over the internal welcome route. ### Additional information No existing issue found for this specific duplicate welcome-route behavior. ### Tests - `ruby -c railties/lib/rails/application/finisher.rb` - `ruby -c railties/test/application/routing_test.rb` - `bundle exec rubocop railties/lib/rails/application/finisher.rb railties/test/application/routing_test.rb` - `cd railties && bin/test test/application/routing_test.rb -i '/not duplicated|appended root/'` - `cd railties && bin/test test/application/routing_test.rb`

Second patch:

github.com/rails/rails

Prevent false leaked-connection reports during reaper maintenance (#57370)

main ← curi:fix-ar-leak-check-reaper-race

opened 12:03AM - 15 May 26 UTC

curi

+61 -8

### Motivation / Background `ActiveRecord::TestCase#check_connection_leaks` sca…ns each pool during teardown to catch connections left owned by background threads. `ConnectionPool::Reaper` can legitimately hold a connection under `reaper_lock` while it performs maintenance. The leak check currently inspects `pool.connections` without taking that lock, so teardown can race the reaper, report a leaked connection owned by `AR Pool Reaper`, and kill the maintenance thread even though no test leaked anything. ### Detail Synchronize the leak scan with `pool.reaper_lock` so teardown waits for any in-flight maintenance to finish before classifying in-use connections as leaks. Add a regression test that reproduces the false positive by holding a connection for maintenance from a thread named `AR Pool Reaper`. The new test fails against `origin/main` and passes with this patch. ### Additional information This surfaced as an unrelated CI failure while validating #57367, where the reported leaked owner was the pool reaper thread. ### Tests - `cd activerecord && ARCONN=postgresql bundle exec ruby -Itest test/cases/test_case_test.rb -v` - `cd activerecord && ARCONN=postgresql bundle exec ruby -Itest test/cases/reaper_test.rb` - `cd activerecord && ARCONN=postgresql bundle exec ruby -Itest test/cases/associations/has_and_belongs_to_many_associations_test.rb` - `bundle exec rubocop activerecord/test/cases/test_case.rb activerecord/test/cases/test_case_test.rb`