Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
# Description We have some machinery in place to trace logs of different pods that relate to the same request by generating request_ids and forwarding them using HTTP headers to the next pod. The next pod will then read this header and attach the id to all its logs. If an incoming request does not have an id the pod will generate a new id based on a counter and use that for the request. The component that generates request ids for incoming user requests actually lives outside the services pod. That means for incoming user requests we never have to worry about generating these ids ourselves. But the autopilot does respond to external requests so it only relies on its internal counter to generate these ids. This is not great since these autogenerated ids don't relate to any auction id in the autopilot. # Changes To make tracing of requests that originated from the autopilot easier we now use the current auction's id as the request id. This should hopefully allow us to identify the auction a requests we sent to the mevblocker proxy was associated with. Also we now for the first time even set the necessary `X-REQUEST-ID` header in the autopilot -> driver requests. I also changed the code to not use the underlying `REQUEST_ID` anymore since we have helper functions that are supposed to be used for that. ## How to test added a unit test to demonstrate the behavior of the helper functions Since the CI only prints logs on failures I copied a log from a local run showing that the request_id is the same as the auction_id: ``` request{id="84"}:/solve{solver=mock_solver auction_id=84}: driver::infra::observe: postprocessing solutions solutions=1 remaining=Ok(1.486682s) ```
- Loading branch information