[SERVER-36843] add assert.commandWorked() around calls in out_from_stale_mongos.js that are expected to work (particularly collection drops are missing this) Created: 24/Aug/18  Updated: 27/Oct/23  Resolved: 24/Aug/18

Status: Closed
Project: Core Server
Component/s: Querying
Affects Version/s: 4.1.2
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Esha Maharishi (Inactive) Assignee: Backlog - Query Team (Inactive)
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Query
Participants:

 Description   

This test caused a BF that is probably not a server issue, but because the test does so many collection drops without asserting that they work that it's unreasonably difficult to debug the BF to figure out where the issue in the test is.



 Comments   
Comment by Esha Maharishi (Inactive) [ 24/Aug/18 ]

Closing this ticket and re-opening the BF.

Comment by Esha Maharishi (Inactive) [ 24/Aug/18 ]

charlie.swanson, good point, I didn't realize the drop() shell helper actually asserts that the drop works. I am taking a closer look at the build failure.

nicholas.zolnierz, yeah, I had originally thought it might be that, but given that the collection is dropped just before the moveChunk that fails, and there is only one moveChunk on the new sharded collection, there shouldn't be any documents on the recipient shard...

Comment by Nicholas Zolnierz [ 24/Aug/18 ]

Aside from the first run, the test is expecting the collections to exist when it drops them. esha.maharishi, the test is also moving chunks around quite a bit, do you think the issue may be related to needing the _waitForDelete flag?

Comment by Charlie Swanson [ 24/Aug/18 ]

esha.maharishi which ones in particular? It looks like this test uses the shell's drop helper, which looks like it will throw an exception if it fails? https://github.com/mongodb/mongo/blob/6937c4f829d3cd1f24745c98bb47f16fa4d8de28/src/mongo/shell/collection.js#L706

Did this drop in particular fail with "ns not found"? If so we could wrap some of the drop calls in assert()'s, but it's a little unclear to me which of them are expecting to drop a collection which already exists, and which are just dropping the collection to make sure it doesn't exist yet, not particularly caring if it did exist before.

Generated at Thu Feb 08 04:44:15 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.