Closed ro0NL closed 2 years ago
hi @ro0NL , thanks for asking. that sounds like a good idea to me, as long as we can do that without sending the id to the backend. do you want to propose how this could be implemented in a pull request?
IIUC we could generate a UUID in a local variable, and keep track of it by ref ...
btw, this also relates to https://github.com/php-http/message/issues/145 as this library is the caller. But i was planning to create another issue for it, if such api is available upstream. Just a heads up ;)
ah, i see. then the Formatter would also have to expect that request id in its methods? if i understood correctly, we should probably do a new interface for the formatter then, and deprecate the old one.
RE UUID: would uniqid be good enough? then we don't need to include a uuid library.
i think uniqid would generally work. Im not sure how a new interface helps, im talking about log context:
https://github.com/php-http/logger-plugin/commit/fa34df71880eb565b5cf0c39f0d9fa08435d7728
https://github.com/php-http/logger-plugin/commit/9ff779995d68e8b955bc96bf4307fa4e3fe61a7f would actually dedup the log message
oh, i see. yeah that commit looks good to me, do you want to create a pull request with it?
in the changelog we should mention that if your logger is configured to ignore info
messages, you want to configure a fingers-crossed logger to log the request in case of a response error.
See #19, logger configuration is out of scope IMHO.
Currently the request log is duplicated in the response log.
It is overhead in terms of logsize, neither do you know which request log really belongs to a response log in case of identical requests.
What about using a shared log context ID, that is unique per request. Solving both issues at once :)