Ref: https://github.com/rails/rails/pull/43282
Ref: https://github.com/rails/rails/pull/43561
It can be legitimate for subscriber to want to bubble up some exception
to the caller, so wrapping it change the exception class which might break
the calling code expecting a specific error.
We can minimize this by only using InstrumentationSubscriberError
when more than one subscriber raised.
It is not uncommon for `sql.active_record` subscribers to rely on
thread local or fiber local state. For instance the `buffered-logger`
gem buffer the logs in a thread variable.
With the introduction of async queries, the `sql.active_record`
events can now be produced from a background thread and that break
some expectations.
This makes it hard for subscriber to map the event to the request
or job that scheduled it.
That is why I believe we should instead store the event and
publish it back on the calling thread when the results are
accessed.
In cases where a notification subscriber includes methods to support
both Evented and Timed events, Evented should take priority over Timed.
This allows subscribers to be backwards compatible (older Rails only
allows Timed events) while defaulting to newer behavior.
Jean Boussier