[SERVER-66811] mongos successfully drops indexes with unsatisfiable write concern Created: 26/May/22  Updated: 01/Jun/22  Resolved: 01/Jun/22

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

Type: Bug Priority: Major - P3
Reporter: Oleg Pudeyev (Inactive) Assignee: Randolph Tan
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to RUBY-2947 Test against 5.2 and 6.0 servers Closed
Operating System: ALL
Sprint: Sharding NYC 2022-05-30, Sharding NYC 2022-06-13
Participants:

 Description   

Ruby driver has a test which attemps to drop an index using a write concern having w > # of nodes in the deployment. This test expects a failure from the server which it gets in 3.6 through 5.2 and 6.0 through rc1.

6.0.0-rc7 and latest server do not produce a failure when in sharded topology. The lack of failure appears to have started with rc2. Standalone and replica sets behave as expected (produce failure) also in 6.0 and latest.

Repro: https://github.com/p-mongo/tests/tree/master/server-s-index-drop

Relevant code:

client = Mongo::Client.new(['localhost'], database: 'test')
 
client['foo'].indexes.create_one(test: 1)
client.with(write_concern: {w: 40})['foo'].indexes.drop_one(test: 1)

Result on 6.0 rc2-rc5, rc7 & latest: no error

Result on pre-6.0 & 6.0 rc1:

	20: from test.rb:6:in `<main>'
	19: from /var/lib/gems/2.5.0/gems/mongo-2.17.1/lib/mongo/index/view.rb:87:in `drop_one'
	18: from /var/lib/gems/2.5.0/gems/mongo-2.17.1/lib/mongo/index/view.rb:287:in `drop_by_name'
	17: from /var/lib/gems/2.5.0/gems/mongo-2.17.1/lib/mongo/client.rb:1067:in `with_session'
	16: from /var/lib/gems/2.5.0/gems/mongo-2.17.1/lib/mongo/index/view.rb:296:in `block in drop_by_name'
	15: from /var/lib/gems/2.5.0/gems/mongo-2.17.1/lib/mongo/operation/shared/polymorphic_operation.rb:35:in `execute'
	14: from /var/lib/gems/2.5.0/gems/mongo-2.17.1/lib/mongo/server.rb:448:in `with_connection'
	13: from /var/lib/gems/2.5.0/gems/mongo-2.17.1/lib/mongo/server/connection_pool.rb:639:in `with_connection'
	12: from /var/lib/gems/2.5.0/gems/mongo-2.17.1/lib/mongo/operation/shared/polymorphic_operation.rb:37:in `block in execute'
	11: from /var/lib/gems/2.5.0/gems/mongo-2.17.1/lib/mongo/operation/shared/executable.rb:65:in `execute'
	10: from /var/lib/gems/2.5.0/gems/mongo-2.17.1/lib/mongo/operation/shared/executable.rb:65:in `tap'
	 9: from /var/lib/gems/2.5.0/gems/mongo-2.17.1/lib/mongo/operation/shared/executable.rb:66:in `block in execute'
	 8: from /var/lib/gems/2.5.0/gems/mongo-2.17.1/lib/mongo/operation/shared/response_handling.rb:33:in `validate_result'
	 7: from /var/lib/gems/2.5.0/gems/mongo-2.17.1/lib/mongo/operation/shared/response_handling.rb:93:in `unpin_maybe'
	 6: from /var/lib/gems/2.5.0/gems/mongo-2.17.1/lib/mongo/operation/shared/response_handling.rb:34:in `block in validate_result'
	 5: from /var/lib/gems/2.5.0/gems/mongo-2.17.1/lib/mongo/operation/shared/response_handling.rb:54:in `add_error_labels'
	 4: from /var/lib/gems/2.5.0/gems/mongo-2.17.1/lib/mongo/operation/shared/response_handling.rb:35:in `block (2 levels) in validate_result'
	 3: from /var/lib/gems/2.5.0/gems/mongo-2.17.1/lib/mongo/operation/shared/response_handling.rb:107:in `add_server_diagnostics'
	 2: from /var/lib/gems/2.5.0/gems/mongo-2.17.1/lib/mongo/operation/shared/response_handling.rb:36:in `block (3 levels) in validate_result'
	 1: from /var/lib/gems/2.5.0/gems/mongo-2.17.1/lib/mongo/operation/result.rb:314:in `validate!'
/var/lib/gems/2.5.0/gems/mongo-2.17.1/lib/mongo/operation/result.rb:348:in `raise_operation_failure': [100:UnsatisfiableWriteConcern]: Not enough data-bearing nodes; Error details: { writeConcern: { w: 40, wtimeout: 0, provenance: "clientSupplied" } } at shard01 (on localhost) (Mongo::Error::OperationFailure)



 Comments   
Comment by Oleg Pudeyev (Inactive) [ 31/May/22 ]

We changed the Ruby driver to use w:4000 for testing (https://github.com/mongodb/mongo-ruby-driver/pull/2511).

Comment by Randolph Tan [ 26/May/22 ]

Note that in current head, mongos converts the command into {w: majority} for a number of ddl operations (it keeps the wtimeout value if it's less than 60s), this is why sending a large w number no longer throws an error. Some of the commands include: collMod, shardCollection, drop, dropDatabase, dropIndex, renameCollection. The list of commands that share this behavior may also expand in the future.

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