Use finish_with_state inside Rack::Logger#44454
Conversation
This ensures that the finish instrumenter is sent to the same subscribers that the initial request was sent to. This solves an issue where in a threaded environment the dynamic subscriptions from ActionDispatch::ServerTiming would cause a mismatch in the number of subscriptions to a topic, which would pop too many values off of the thread-local stacks, leading to invalid events being sent to subscribers. Fixes rails#44167
|
i think this should prevent this specific event from triggering #44167 because it syncs the number of pushes to the shared stack with the number of pops. however, it will not prevent other events from triggering the bug, e.g. it will recur if any commonly used gem calls |
|
Hello @jhawthorn and @jaynetics I'll be explicit about what I've done as I haven't done this before. I took my reproduction application and changed Rails in the Gemfile to:
The rails version in the I then tried to reproduce the bug by stopping and starting the server a number of times and couldn't reproduce the bug. |
Use finish_with_state inside Rack::Logger
This ensures that the finish instrumenter is sent to the same subscribers that the initial request was sent to.
This solves an issue where in a threaded environment the dynamic subscriptions from
ActionDispatch::ServerTimingwould cause a mismatch in the number of subscriptions to a topic, which would pop too many values off of the thread-local stacks, leading to invalid events being sent to subscribers.I would like to backport this to 7-0-stable
Fixes #44167
cc @notapatch @jaynetics