Add RequestID to generate unique Identifier for each request

[adam-fowler]

Previously this was just an incrementing Int, but it was pointed out that ids across instances of an Hummingbird app would clash as they all started at zero. This is now two integers one identifying the instance and the other an incrementing UInt64 started at a random point in its range. This has all been encapsulated in a RequestID type.

[codecov]

Codecov Report

Attention: 1 lines in your changes are missing coverage. Please review.

Comparison is base (6bd1e0c) 84.62% compared to head (b96fefe) 84.62%.
Report is 1 commits behind head on main.

Files	Patch %	Lines
Sources/Hummingbird/Server/RequestID.swift	92.85%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #326   +/-   ##
=======================================
  Coverage   84.62%   84.62%           
=======================================
  Files          78       79    +1     
  Lines        4831     4845   +14     
=======================================
+ Hits         4088     4100   +12     
- Misses        743      745    +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[github-actions]

Pull request benchmark comparison [ubuntu-latest] with 'main' run at 2023-12-31T17:10:54+00:00
Pull request had performance regressions

[Joannis]

I agree with this change, at the very least for 2.x. Though I'm wondering to what extend users depend on the nature of this having been an integer

[adam-fowler]

I agree with this change, at the very least for 2.x. Though I'm wondering to what extend users depend on the nature of this having been an integer

This was a request from someone using v1. So I'd prefer to merge into v1.

Hmmm, I don't know about the integer thing, The fact it was an integer is really a side effect of how the id was generated. I can be explicit in the release notes about the id change and how it might affect users who depended on it being an integer that fitted into a Int64.

[MahdiBM]

I realize there might be someone somewhere somehow counting on the ID being an Int, but that's quit unlikely as the id is only used in the log statement (unlike Vapor which exposes the request id to the public, for reasons that i think are legitimate but i still don't remember).

[MahdiBM]

• It's certainly cleaner this way, but it still feels unnecessary to transform high to a String once per RequestID.description call, considering .description will be common due to the logging statement.
• Doesn't this hex description (partially) defeat the point of having a nice easily-human-readable integer as the request's id? At that point a random UUID could just be the simpler solution although i assume it's somewhat more costly to create.

[adam-fowler]

Good point about transforming high repeatedly.

I'm not using UUID because one it requires Foundation and two it is slower to generate. I reduced it to hex to shorten the id and the first 16 chars end up being a process id. Anyway not sure a 128bit integer is human readable.

[MahdiBM]

Hmm fair enough. I now think it's fine being a hex 🤔 i was thinking someone might rather read/have it as a decimal number, but I can't come up with enough reasons why that should be important. They can always turn the hex back to an integer trivially if it's that important 🤔

[adam-fowler]

I realize there might be someone somewhere somehow counting on the ID being an Int, but that's quit unlikely as the id is only used in the log statement (unlike Vapor which exposes the request id to the public, for reasons that i think are legitimate but i still don't remember).

I think @Joannis requested that. He requested the same of HB and a String is returned as an id. If someone is converting that back to an integer I would want to discourage that anyway.