[SERVER-33256] shardCollection gets DuplicateKeyError if it retries inserting to config.collections after failing to wait for writeConcern Created: 09/Feb/18 Updated: 05/Nov/18 Resolved: 05/Nov/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 3.6.2, 3.7.1 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Esha Maharishi (Inactive) | Assignee: | Randolph Tan |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | sharding-wfbf-day | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||||
| Backport Requested: |
v3.6
|
||||||||||||||||||||||||
| Sprint: | Sharding 2018-11-19 | ||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||
| Linked BF Score: | 5 | ||||||||||||||||||||||||
| Description |
|
This write done by _configsvrShardCollection to write the collection entry to the sharding catalog uses majority writeConcern and the kIdempotent RetryPolicy. If it fails to wait for writeConcern, it will be retried because of the kIdempotent policy, and the retry will see DuplicateKeyError because the document has already been written locally. |
| Comments |
| Comment by Esha Maharishi (Inactive) [ 05/Nov/18 ] |
|
Based on conversation with renctan, if the ShardRegistry is allowed to contain uncommitted data, the ShardRegistry should be cleared on rollback. |
| Comment by Randolph Tan [ 05/Nov/18 ] |
|
I think the reason it was getting duplicate key error was because it was using an older snapshot. I'm convinced this is the case because: (1) update is upsert: true, so it should have been a no-op update if was retried using the latest view of the data and (2) the abnormally high writeConflict count also supports this. I believe this has been fixed by |