[SERVER-53751] findMatchingLogLines js helper function doesn't work when command's log verbosity level is 2 Created: 13/Jan/21  Updated: 29/Oct/23  Resolved: 05/Feb/21

Status: Closed
Project: Core Server
Component/s: Testing Infrastructure
Affects Version/s: 4.9.0
Fix Version/s: 4.9.0

Type: Bug Priority: Minor - P4
Reporter: Tommaso Tocci Assignee: David Percy
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Problem/Incident
is caused by SERVER-31368 Log time spent waiting for other shar... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Steps To Reproduce:

resmoke.py --mongodSetParameters="{logComponentVerbosity: {command: 2}}" --suite=sharding jstests/sharding/log_remote_op_wait.js

Sprint: Query 2021-02-08
Participants:

 Description   

findMatchingLogLines js helper function is not able to parse logs line when the command log component verbosity level is higher then 1.



 Comments   
Comment by Githook User [ 05/Feb/21 ]

Author:

{'name': 'David Percy', 'email': 'david.percy@mongodb.com', 'username': 'dpercy'}

Message: SERVER-53751 Make some findMatchingLogLine tests tolerate higher log level

Previously, these two tests would fail when run on a higher log level, because
more than one log line would contain the expected comment.
Branch: master
https://github.com/mongodb/mongo/commit/c30378eaeb628b741b152b69caa4e89d3b9aefaf

Comment by David Percy [ 01/Feb/21 ]

It looks like the bug is in this specific test, log_remote_op_wait.js, rather than the helper. The test is looking for a specific log line, so it can assert it includes the "remoteOpWaitMillis" field. But the search criteria it uses are not strict enough, so at higher verbosity it's making assertions about the wrong log line.

This should be a pretty small fix; I think just adding msg: "Slow query" to the search criteria.

jstests/noPassthrough/profile_filter.js may need a similar fix.

Comment by Tommaso Tocci [ 19/Jan/21 ]

I'm sorry for the lack of in formations on the original formulation of this ticket.

I just wanted to insist that even if it doesn't have a high priority this is a real bug and not an improvement.
In fact this bug is making impossible to just run the sharding suite:

python3 buildscripts/resmoke.py run --mongodSetParameters="{logComponentVerbosity: {command: 2}}" --suite=sharding

In fact if the command's log component verbosity is higher then 1, the `jstests/sharding/log_remote_op_wait.js` will constantly fail.

Again... I would strongly recommend to treat this as a bug and not as an improvement.

Generated at Thu Feb 08 05:31:46 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.