-
Type:
Bug
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: Sharding
-
Fully Compatible
-
ALL
On the CRUD/DDL fsm workload there is an error that can happen if an update happens during a rename:
Error: write failed with error: {
"nMatched" : 0,
"nUpserted" : 0,
"nModified" : 0,
"writeError" : {
"code" : 175,
"errmsg" : "collection renamed from 'test0_fsmdb0.fsmcoll00' to 'test0_fsmdb0.fsmcoll01615840135680'. UUID 020b4e1f-f1d1-4af6-8c1a-371e774082ec"
}
}
_getErrorWithCode@src/mongo/shell/utils.js:25:13
quietlyDoAssert@jstests/concurrency/fsm_libs/assert.js:53:18
assert.writeOK@src/mongo/shell/assert.js:863:13
_assertCommandWorked@src/mongo/shell/assert.js:704:17
assert.commandWorked@src/mongo/shell/assert.js:811:16
wrapAssertFn@jstests/concurrency/fsm_libs/assert.js:65:13
assertWithLevel/</assertWithLevel[fn]@jstests/concurrency/fsm_libs/assert.js:104:13
CRUD@jstests\concurrency\fsm_workloads\random_DDL_CRUD_operations.js:141:13
runFSM@jstests/concurrency/fsm_libs/fsm.js:132:17
@eval:8:9
main@jstests/concurrency/fsm_libs/worker_thread.js:217:17
@eval:5:12
@eval:3:24
_threadStartWrapper@:26:16
This ticket can be solved by surrounding the write operations with a try/catch and ignore this specific error because it is related to the query planner. Before that we should ensure that:
- The same error happens on insert and remove
- The error is the same if we are running a replica set
- is caused by
-
SERVER-52813 No-stepdown concurrency suites for the new DDL paths
-
- Closed
-