[SERVER-66503] ObjectIsBusy thrown in unindex Created: 16/May/22 Updated: 06/Feb/24 Resolved: 20/Oct/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 6.2.0-rc0, 6.0.14 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Yuhong Zhang | Assignee: | Gregory Noma |
| 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 | ||||||||||||||||||||||||||||||||
| Backport Requested: |
v6.0
|
||||||||||||||||||||||||||||||||
| Sprint: | Execution Team 2022-06-27, Execution Team 2022-07-11, Execution Team 2022-09-05, Execution Team 2022-09-19, Execution Team 2022-10-03, Execution Team 2022-10-17, Execution Team 2022-10-31 | ||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||
| Linked BF Score: | 135 | ||||||||||||||||||||||||||||||||
| Description |
|
When running initial_sync_move_forward.js, we always get
even though the test passes. |
| Comments |
| Comment by Githook User [ 06/Feb/24 ] | |||||
|
Author: {'name': 'Gregory Noma', 'email': 'gregory.noma@gmail.com', 'username': 'gregorynoma'}Message: (cherry picked from commit e73a86e6dd30ea480c8449f77b93973d1fc94218) GitOrigin-RevId: d39b794e714f18ba3b96b8bca24df954cc5e4320 | |||||
| Comment by Githook User [ 20/Oct/22 ] | |||||
|
Author: {'name': 'Gregory Noma', 'email': 'gregory.noma@gmail.com', 'username': 'gregorynoma'}Message: | |||||
| Comment by Gregory Noma [ 12/Oct/22 ] | |||||
|
When committing the _id index for logical initial sync, we handle a duplicate record by deleting it. This involves removing the corresponding index entries, including from the same _id index. Since we have an open bulk cursor on the _id index table, attempting to open a new cursor for this removal results in an EBUSY which we convert to ObjectIsBusy. This error gets swallowed in SortedDataIndexAccessMethod::removeOneKey, resulting in the aforementioned log message and backtrace. | |||||
| Comment by Yuhong Zhang [ 15/Sep/22 ] | |||||
|
The stacktrace is really misleading! I think we would still want to investigate why the assertion fails in the first place and confirm whether it's expected. This is expected to be prioritized in the next couple of weeks. | |||||
| Comment by Daniel Gottlieb (Inactive) [ 15/Sep/22 ] | |||||
|
That's the test evergreen is reported as failing, yes. But that error is basically saying "couldn't connect to a node". That node crashed in an earlier test:
Ah, apologies. I see now. That's not an actual crash. If that's an expected assertion + internal retry and we don't intend on fixing it, can we avoid the stack trace? | |||||
| Comment by Yuhong Zhang [ 15/Sep/22 ] | |||||
|
daniel.gottlieb@mongodb.com is the failing test jstests/replsets/currentOp_during_automatic_reconfig.js? I couldn't seem to find any logs related to the issue this ticket described. The reason why we don't have a BF is that we have seen this "assertion failure" message even in the successful runs and so far there hasn't been a BF really caused by it. |