CLDSRV-992: Match server access log entries instead of asserting an exact count - #6276
Conversation
Hello anurag4dsb,My role is to assist you with the merge of this Available options
Available commands
Status report is not available. |
Incorrect fix versionThe
Considering where you are trying to merge, I expected to find at least:
Please check the |
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
❌ 2 Tests Failed:
View the top 1 failed test(s) by shortest run time
View the full list of 1 ❄️ flaky test(s)
To view more test analytics, go to the Test Analytics Dashboard |
af4f4a0 to
588f65f
Compare
…xact count (backport of CLDSRV-923) The serverAccessLogs tests asserted an exact entry count per operation while isolating tests by truncating the shared access-log file. That file is shared by the whole server process, and a request's line is written on the response 'close' event, which under HTTP keep-alive can fire much later, on socket teardown. A request from another suite (captured in CI: GetObject on buckettestgetobject, from test/object/get.js) can therefore have its line written during a serverAccessLogs test, landing inside the truncate window and inflating the count by one. The failing operation varied run to run because the victim was whichever test the foreign write happened to land in. Match each expected entry against the collected entries by its fields and ignore anything else, instead of asserting logEntries.length === totalExpected. Unordered groups are flattened and matched independently, so interleaved foreign entries are tolerated regardless of when they arrive. Reordered relative to upstream: the fix is applied to the unformatted file so it reviews on its own, and the prettier pass follows in the next commit. Backport of #6211 Issue: CLDSRV-992 (cherry picked from commit 6aa67d9)
…LDSRV-923) Pure formatting pass with no behavior change, kept in its own commit so the functional change before it reviews cleanly. The file predated prettier adoption and had never been reformatted. Backport of #6211 Issue: CLDSRV-992 (cherry picked from commit 06a0bfe)
588f65f to
5371bb1
Compare
|
/approve |
Build failedThe build for commit did not succeed in branch improvement/CLDSRV-992-9.3.13-server-access-log-match The following options are set: approve |
In the queueThe changeset has received all authorizations and has been added to the The changeset will be merged in:
The following branches will NOT be impacted:
There is no action required on your side. You will be notified here once IMPORTANT Please do not attempt to modify this pull request.
If you need this pull request to be removed from the queue, please contact a The following options are set: approve |
|
I have successfully merged the changeset of this pull request
The following branches have NOT changed:
Please check the status of the associated issue CLDSRV-992. Goodbye anurag4dsb. |
5 participants
Backport of CLDSRV-923, from #6211 (
6aa67d9b6, plus its prettier prerequisite06a0bfe8e), identical to #6275 on development/9.3. Nothing forward-ports into hotfix lines, so this flake has kept firing here: twice in the CLDSRV-992 sample alone, runs 33646458152 and 33674946535.The access-log file is shared by the whole server process and a line is written on the response
closeevent, which under keep-alive can fire much later, during another suite's truncate window. A foreign GetObject onbuckettestgetobjectfromtest/object/get.jstherefore inflates the count, which is why the victim varied between runs: bucketPut in one, objectDelete in the next.Review commit 1 only. Commit 2 is a pure prettier pass, cherry-picked with its original author; the functional change is 83 lines and the resulting file is byte-identical to development/9.4's, green there since July. If you have already reviewed #6275 this is the same two commits and should be quick.