$ the-wire · showcase
Parameter filters get cached, transactions roll back on before_commit errors
By RepoJournal · Filed · About Rails · Composed from the cited sources · methodology
Rails' parameter filtering now pays its compile cost once per process instead of once per request, and a long-standing transaction bug where a raising before_commit callback left a connection checked back into the pool still inside an open transaction is fixed.
Cache ActiveSupport::ParameterFilter instances across requests rails/rails
ActionDispatch::Request memoized its ParameterFilter on the request object, which is recreated every request, so each one re-ran ParameterFilter.new and Regexp#to_s across the whole configured filter list. The filter is now cached across requests, taking that per-request compilation off the hot path.
Roll back when a before_commit callback raises a rollback error rails/rails
within_new_transaction rescued TransactionRollbackError around commit_transaction and skipped the ROLLBACK, but that rescue also covered before_commit_records, which runs before COMMIT is sent. A before_commit callback that raised left the transaction open and the connection returned to the pool still inside it; invalidation now happens next to transaction.commit.
Freeze events emitted by ActiveSupport::EventReporter rails/rails
EventReporter#notify passed one shared event hash to every subscriber, so a subscriber that mutated it changed what every later subscriber saw, in subscription order, and could even restore payload values that parameter filtering had stripped. The event hash, its payload hash, and the source location are now frozen before subscribers receive them.
Add test for OOB/in_order_of/CTE rails/rails
Coverage for out-of-band batching combined with in_order_of and CTEs landed, closing out the case tracked by the two related issues.
