[SERVER-48085] Suppress "unrecognized parameter waitForStepDownOnNonCommandShutdown" log Created: 11/May/20  Updated: 29/Oct/23  Resolved: 14/May/20

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: 4.7.0

Type: Task Priority: Major - P3
Reporter: A. Jesse Jiryu Davis Assignee: Tess Avitabile (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by SERVER-48127 Do not pollute logs with expected ass... Closed
is duplicated by SERVER-48166 Scary-looking message about removed s... Closed
Related
Backwards Compatibility: Fully Compatible
Sprint: Repl 2020-05-18
Participants:
Linked BF Score: 40

 Description   

In ReplSetTest, starting with SERVER-46952, we log on shutdown:

assert: command failed: {
"ok" : 0,
"errmsg" : "attempted to set unrecognized parameter [waitForStepDownOnNonCommandShutdown], use help:true to see options "
}

This can confuse humans and tools that search for assertion failures to diagnose test failures. I propose we check for this specific error from setParameter and suppress it in replsettest.js, while allowing other errors from setParameter to bubble up.



 Comments   
Comment by Githook User [ 14/May/20 ]

Author:

{'name': 'Tess Avitabile', 'email': 'tess.avitabile@mongodb.com', 'username': 'tessavitabile'}

Message: SERVER-48085 Suppress 'unrecognized parameter waitForStepDownOnNonCommandShutdown' log
Branch: master
https://github.com/mongodb/mongo/commit/fc5f59fcd4e5c31d5c1a25e5e3a0487df2dfe75e

Comment by Tess Avitabile (Inactive) [ 11/May/20 ]

Got it, thanks for pointing that out.

Comment by Max Hirschhorn [ 11/May/20 ]

tess.avitabile, I don't believe the changes from 20df781 as part of SERVER-47876 fully addressed this issue. We're still logging an "attempted to set unrecognized parameter" error message along with the JavaScript stacktrace as a result of this part of the doassert() function.

https://logkeeper.mongodb.org/lobster/build/b89c9a93e6a933a3cdbfec0af82dfcad/test/5eb96a63be07c4311d1361ad#bookmarks=0%2C2380%2C5642&l=1

Comment by Tess Avitabile (Inactive) [ 11/May/20 ]

I agree! I addressed this in SERVER-47876.

Comment by Max Hirschhorn [ 11/May/20 ]

Is there a reason we call assert.commandWorked() inside of a try/catch block anyway? It seems like we could printjson() the response explicitly if all we were interested in was logging any errors via doassert() being called.

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