Summary

Usually, opening a read cursor on an object being bulk loaded would return EBUSY, indicating the object is not accessible._ _It can be the case that opening a bulk cursor and opening a read (or any other) cursor happens concurrently, and the read cursor does not return EBUSY and instead blocks trying to acquire the read lock. This would be because by the time the bulk cursor has set the WT_BTREE_BULK flag, the reader has already performed the check.

This by itself wouldn't be an issue, but when MongoDB layer locks are involved, we can end up in a deadlock as described in SERVER-77018.

See this comment with suganthi.mani@mongodb.com's findings for more details.

Acceptance criteria

Cursors consistently return EBUSY when conflicting with a bulk cursor, instead of being timing dependant whether an error is returned or the call gets blocked waiting for lock.

Related tickets
SERVER-77018