-
Notifications
You must be signed in to change notification settings - Fork 34
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
Allow configure log context for request_* events #484
Comments
You still could bind values for the finish and failure because the bind will persist only for the last log. However it needs a solution for the request started. I was not planning to support the subclassing of the RequestMiddleware yet but I will do it officially eventually. I want appropriate tests and a decent interface. Subclassing support means that any future change could break the setup of users. I don't like that aspect. I don't want people to subclass it unless they need to do major advanced changes. I'd like to find a solution for your use case with simpler implementation. Ex: adding an extra dict to the signals that will be added to the log of the event. Any other suggestion? |
Sounds like a good idea. And if this extra dict would contains the current context from logging methods (e.g. |
Hello!
I need to configure context for
request_started
/request_finished
events, for example to add additional headers or to splitrequest
context value intorequest_method
andrequest_url
. Or even log request and response body or headers in some cases. At the moment I can't do this without copy-paste and modifyprepare
andhandle_response
methods in my own class which inherits fromRequestMiddleware
.I know about
bind_extra_request_metadata
andbind_extra_request_finished_metadata
signals, but they add values to global context and I don't want these values to be global.Maybe something like this:
Then in my own class I will be able to do this:
I can make a PR if you OK with this idea.
Thanks.
The text was updated successfully, but these errors were encountered: