[SERVER-32534] Have UnorderedFastKeyTable iterators error if the table had been modified. Created: 03/Jan/18  Updated: 27/Oct/23  Resolved: 28/May/19

Status: Closed
Project: Core Server
Component/s: Internal Code
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Daniel Gottlieb (Inactive) Assignee: DO NOT USE - Backlog - Platform Team
Resolution: Gone away Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-32532 Two-phase dropDatabase may not replic... Closed
related to SERVER-32251 dropCollection/dropDatabase must be t... Closed
Participants:

 Description   

There isn't a clearly defined behavior of how modifications done to an UnorderedFastKeyTable will affect what values a scanning iterator will observe. SERVER-32532 is an example of where the iterator is expecting to observe all items in the map, but due to underlying function calls erasing and adding items back in, the required behavior is not achieved.

I apologize that this ticket isn't proposing a complete specification, but I believe at the very least, moving and accessing an iterator should cause a crash (debug mode only?) if the underlying map has had items both removed and added since the iterator's creation. That would have been sufficient for surfacing SERVER-32532.



 Comments   
Comment by Mira Carey [ 28/May/19 ]

Ever since we went to abseil's map types, this is no longer relevant

Comment by Mira Carey [ 03/Jan/18 ]

At the least, we should document what our iterator invalidation rules are, and whether erase/add preserve order.

Generated at Thu Feb 08 04:30:31 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.