A bug in WiredTiger caused updates to not be visible to concurrent readers immediately upon commit. Applications that rely on updates being visible immediately (including MongoDB) temporarily see unexpected results. After waiting or restarting, all committed data would be present and visible, but reads during this window could see "holes" with recent changes missing.

Background: WiredTiger uses transaction snapshots to determine which versions of updates should be visible to readers. When a transaction T starts, it builds a list of transaction IDs of running transactions (the transactions concurrent with T). Updates created with those transaction IDs are not visible to reads in T.

WiredTiger has avoided locking in the transaction subsystem by having threads race to allocate transaction IDs. Multiple threads can publish the same ID but only one thread wins the race and goes on to use that ID for updates. Other threads could temporarily leave a transaction ID published in the global state table. If T completes quickly enough that another thread still has T's ID published after T commits, then T's ID will appear in snapshots after T commits, delaying when T's updates become visible.