CLDSRV-992: Match server access log entries instead of asserting an exact count - #6287
Open
anurag4DSB wants to merge 1 commit into
Open
CLDSRV-992: Match server access log entries instead of asserting an exact count#6287anurag4DSB wants to merge 1 commit into
anurag4DSB wants to merge 1 commit into
Conversation
…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. This branch's copy of the file differs from the 9.3 line, so the pick needed three hunks resolved by hand; no prettier commit accompanies it, because unlike the 9.3 backport the surrounding file was never reformatted here and doing so would bury the change. Backport of #6211 Issue: CLDSRV-992
Contributor
Hello anurag4dsb,My role is to assist you with the merge of this Available options
Available commands
Status report is not available. |
Contributor
Incorrect fix versionThe
Considering where you are trying to merge, I expected to find at least:
Please check the |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files
@@ Coverage Diff @@
## hotfix/9.2.36 #6287 +/- ##
=================================================
- Coverage 84.37% 84.31% -0.07%
=================================================
Files 204 204
Lines 13162 13162
=================================================
- Hits 11106 11097 -9
- Misses 2056 2065 +9
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
tcarmet
approved these changes
Sep 8, 2026
jonathan-gramain
approved these changes
Sep 9, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Backport of CLDSRV-923, from #6211 (
6aa67d9b6). That fix landed on development/9.4 and 9.5 only and nothing forward-ports into hotfix lines, so this branch still asserts an exact log-entry count and is still exposed to the flake. The access-log file is shared by the whole server process and a line is written on the responsecloseevent, 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 test varied between runs.Cherry-picked from #6211, unchanged. The whole functional change:
waitForLogsis replaced byreadLogLines+entryMatchesExpected+waitForExpectedLogs, which match each expected entry against the collected entries by field and ignore anything else, instead of assertinglogEntries.length === totalExpected. Unordered groups are flattened and matched independently. The failure message now also names which expected entries never arrived, rather than only reporting a count mismatch.Changed by hand. Three conflict hunks, because this branch's copy of the file differs from the 9.3 line. All three were resolved by taking the incoming (upstream) side, the same resolution used for the 9.3 backports in #6275 and #6276:
waitForLogsfunction body, replaced wholesale by the three new helpers;waitForAction's inline file read, switched toreadLogLines(filePath);it(...)block, dropping thetotalExpectedcomputation and the exact-count assertion in favour ofwaitForExpectedLogs.No prettier commit here, unlike #6275 and #6276, because prettier is not used on this branch.
hotfix/9.2.36has no prettier dependency, noprettier:diffscript and noprettier.config.cjs/.prettierignore; development/9.3 and hotfix/9.3.13 have all of them, which is why the backports there carry the upstream formatting commit. Adding one here would mean introducing prettier to the branch, which is well outside a flaky-test fix, so the change is the 83-line functional pick and nothing else.How I checked the pick is faithful. The resulting file still differs from development/9.4 in 1123 lines, but none of those differences fall in the code this fix touches (
waitForExpectedLogs,entryMatchesExpected,readLogLines,totalExpected); the remainder is pre-existing formatting drift on this branch.waitForLogshas no remaining references, and CI-equivalent eslint andnode --checkboth pass.