-
Notifications
You must be signed in to change notification settings - Fork 897
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix key collision with Thread[:current_request] #20973
Conversation
Now that we've moved to manageiq-loggers, the ContainerLogger has code that expects that if Thread[:current_request] is set, it will be a request object that responds to :request_id. The RequestStartedOnMiddleware, however, happens to use the same key and stores only the request path, leading to `undefined method request_id for "/path/to/wherever"` Since this particular key's usage is isolated to the middleware, we can name it whatever we want, so this commit chooses a name that is less likely to collide.
cc @abellotti |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just an idea to make it a bit more unique.
(other than that, though, I think this change makes sense, to 👍 from me)
Checked commit Fryguy@0109f04 with ruby 2.6.3, rubocop 0.82.0, haml-lint 0.35.0, and yamllint |
@Fryguy should this go back to kasparov? |
Fix key collision with Thread[:current_request] (cherry picked from commit c52be90)
Kasparov backport details:
|
Now that we've moved to manageiq-loggers, the ContainerLogger has code
that expects that if Thread[:current_request] is set, it will be a
request object that responds to :request_id. The
RequestStartedOnMiddleware, however, happens to use the same key and
stores only the request path, leading to
undefined method request_id for "/path/to/wherever"
Since this particular key's usage is isolated to the middleware, we can
name it whatever we want, so this commit chooses a name that is less
likely to collide.