While looking into a related issue i noticed that on prod web requests we have uuidv4 request ids, but from mwscript we have 24 char hex values:
> MediaWiki\Http\Telemetry::getInstance()->getRequestId() = "c3793e05fbb9d4401b95475b" > strlen(MediaWiki\Http\Telemetry::getInstance()->getRequestId()) = 24
Likely they should both utilize the same format for request ids.
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Add option for generated reqid to be uuidv4 | mediawiki/core | master | +38 -0 |
Change #1248913 had a related patch set uploaded (by CDanis; author: CDanis):
[mediawiki/core@master] Add option for generated reqid to be uuidv4
Change #1248913 merged by jenkins-bot:
[mediawiki/core@master] Add option for generated reqid to be uuidv4
If MediaWiki doesn't get any requqest id ( or by x-request-id or by UNIQUE_ID ) uses a wfRandomString( 24 ) to provide an unique request identifier. I don't know that time, but from what I read - I assume that the 24 character random string was picked to match what unique_id apache mod is doing:
The UNIQUE_ID environment variable is constructed by encoding the 144-bit (32-bit IP address, 32 bit pid, 32 bit time stamp, 16 bit counter, 32 bit thread index) quadruple using the alphabet [A-Za-z0-9@-] in a manner similar to MIME base64 encoding, producing 24 characters.
Source: Apache documentation: https://httpd.apache.org/docs/current/mod/mod_unique_id.html
The UNIQUE_ID was added in 2016 - Iaf90c20c330e0470b9b98627a0228cadefd301d1 - ( using Apache + mod_unique_id )
The X-Request-Id was added in 2019 - I605471fb8b5bbc290baeecc7d80d9d715cb240c9
So the current code, in theory, depends on a patch from 2016, and if request_id is not set, we do the same what mod_unique_id was doing - generate a random 24-character string.
I wonder if we can:
a) drop the apache mod_unique_id support - we don't use it any more - doesn't hurt us but still an extra code
b) update fallback to match the UUID instead of keeping the old 24 bit character - this way we don't need an extra config variable
Additional note, I just checked if the unique_id has enough entropy to be always unique and from it looks like, there are already some bug reports that module is generating duplicated unique_ids under heavy load with HTTP/2 ( like https://github.com/icing/mod_h2/issues/195 -- already fixed )
And Apache warns that uniqueness is not guaranteed
... there is a 1.5% chance that if time (at one second resolution) repeats itself this child will repeat a counter value, and uniqueness will be broken.
Therefore going with UUIDv4 IMHO is a step in good direction.