[SERVER-41095] Multiversion wildcard index test should account for additional failure scenario on downgrade Created: 10/May/19 Updated: 29/Oct/23 Resolved: 15/May/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Index Maintenance, Querying, Upgrade/Downgrade |
| Affects Version/s: | None |
| Fix Version/s: | 4.1.12 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Charlie Swanson | Assignee: | Charlie Swanson |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Backwards Compatibility: | Fully Compatible | ||||
| Operating System: | ALL | ||||
| Participants: | |||||
| Linked BF Score: | 12 | ||||
| Description |
|
this assertion in wildcard_index_feature_compatability_version.js expects a 4.0 binary to reject a wildcard index that it finds in its catalog on startup. In most cases this is correct, but we have seen at least one scenario where the 4.0 binary mongod will start up without having fully built and persisted the wildcard index before being shut down last time. In such a scenario the mongod will attempt to rebuild the index before figuring out that it doesn't recognize the index specification, resulting in a different error code: 40590. Even though the test waits for replication before shutting down the secondaries, it's still possible that the index build hasn't finished at that point. We should update the test to account for this possibility. |
| Comments |
| Comment by Githook User [ 15/May/19 ] |
|
Author: {'name': 'Charlie Swanson', 'username': 'cswanson310', 'email': 'charlie.swanson@mongodb.com'}Message: |