You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In collector mode each error is recorded when it is added, but its block
was still held until completion. Deferring only makes sense in agent
mode, where blocks run against the duplicate transactions fabricated at
completion. In collector mode there is no benefit to holding them back.
Run the block when the error is added instead. Side effects that target
the current span, such as breadcrumbs, nested errors or custom
instrumentation, then land where the error was reported rather than on
the root span at completion. None of those belong in an error block, but
this puts them in the right place if they are used.
With blocks no longer deferred in collector mode, the error tracking
that supported deferral was doing two jobs at once. `@error_blocks` was
both the set of distinct errors, which drives `last_errors`, the dedup
check and the error limit, and the per-error blocks that only agent mode
runs. Split them. `@errors` is now the distinct-error set, used in both
modes, and `@error_blocks` holds only blocks and is populated only in
agent mode. `@errors` is a Set, so membership is by object identity,
matching how the errors were deduplicated as hash keys before.
Finally, rename `records_errors_eagerly?` to `supports_multiple_errors?`.
The old name described the mechanism. The real question at the call site
is whether the backend can hold more than one error on a transaction.
0 commit comments