Implement request IDs to trace errors

[fengelniederhammer]

We should implement something that makes tracing requests in log files easier. When there are many concurrent requests, it's impossible to see which message belongs to which request.

I propose to implement request ids similar to what we did in LAPIS: GenSpectrum/LAPIS#586. This should be done in the website server and in the backend. Whenever there is already a request id, it should be passed on to the next service when issuing a call (e.g. when the website server calls LAPIS).

[corneliusroemer]

This should also be passed to the preprocessing pipeline, which can then return the id back to the backend

[fengelniederhammer]

The lifetime of such a request ID should be one request (and not longer). We want to be able to trace single request by filtering logs by the ID. I think we should not pass it into the preprocessing pipeline, but of course we can think of another way to identify backend calls issued by one preprocessing run (e.g. by logging the request ids that were returned to the pipeline when pulling the data and submitting the results).

[corneliusroemer]

Right, I misunderstood the scope of this.

Would it still be useful to somehow have an id associated with each iteration of the preprocessing loop. It should originate from the preprocessing pipeline? It generates a UUID, attaches that to the /get-unprocessed-sequences request, but also attaches it later to the /submit-processed-sequences? And the backend logs those UUIDs so we can correlate what happened?

[fengelniederhammer]

I think we don't need that here, since the preprocessing pipeline doesn't do anything in parallel (or does it?). So the logs of one run are in order anyway. The backend would then return a request id on every call, which can be written to the preprocessing log. IMO that's good enough and requires minimal effort.