Pass X-Request-Id if present

[paunik]

Pass the value from the X-Request-Id to the logger context

• pass the X-Request-Id header value if present, pass generated UUID if the header not present

Mentioned:

• Use logger request-id from Heroku's X-Request-ID header #2508

Why:

• We needed a way to trace router -> web -> worker on the logger on the heroku and we found this https://devcenter.heroku.com/articles/http-request-id

Inspiration:

• https://api.rubyonrails.org/classes/ActionDispatch/RequestId.html
• https://http.dev/x-request-id

[gwynne]

This looks fine, aside from the conflict markers left unresolved.

[codecov-commenter]

Codecov Report

Merging #3072 (fdb632d) into main (a4b0715) will increase coverage by 0.00%.
The diff coverage is 100.00%.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #3072   +/-   ##
=======================================
  Coverage   76.21%   76.22%           
=======================================
  Files         211      211           
  Lines        7821     7824    +3     
=======================================
+ Hits         5961     5964    +3     
  Misses       1860     1860           

Files Changed	Coverage Δ
Sources/Vapor/HTTP/Headers/HTTPHeaders+Name.swift	74.07% <ø> (ø)
Sources/Vapor/Request/Request.swift	76.34% <100.00%> (+0.78%)	⬆️

[dannflor]

Beautamous

[penny-for-vapor]

These changes are now available in 4.83.1

[MahdiBM]

Honestly considering this header doesn't make an appearance in MDN, I wouldn't hard-code it like this 🤔

I would instead add a configuration option so other users can configure it "based on headers", and there they could specify the "X-Request-ID" header.

I know this complicates the solution, but we have "tracing" and "task-locals" for logging now which enable you to this yourself to some extent, and caring about this particular header seems out of scope for Vapor to me.

To be clear I still like the idea and I can think of some nice use cases for it.

[gwynne]

@MahdiBM I disagree - X-Request-ID is not an official standard, true, but it is a de facto one. (Enough so, even for people to have gone to the trouble of noting that RFC 6648 deprecated the X- prefix on headers and remarked on the need to find a new name.) Unless you can cite links to any alternate names commonly used for the same purpose, configurability would just bloat the API surface and force users to do additional work without adding any real value.

(And as for it being out of scope, we put Vapor into the scope of caring about request IDs when we made it generate random ones by default.)