[SERVER-30819] Track missing UUIDs encountered during fetchAndInsertMissingDoc Created: 24/Aug/17 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Replication, Storage |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Maria van Keulen | Assignee: | Backlog - Replication Team |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | idempotency, initialSync | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Replication
|
| Participants: |
| Description |
|
If we encounter a collection in fetchAndInsertMissingDoc with a UUID that is unrecognized in the UUIDCatalog, it should be tracked in a missingUUIDs set so that it can be accounted for once the corresponding oplog application drop/rename operation for that collection is reached. At the end of oplog application, we should assert that this missingUUIDs set is empty and all missing UUIDs have been accounted for. |
| Comments |
| Comment by Andy Schwerin [ 25/Aug/17 ] |
|
It's not strictly required. It might be very easy to do in conjunction with the required work that is already taking place, and might constitute sufficient testing of some of that work. Maria and Geert will be better judges of that than I. |
| Comment by Ian Whalen (Inactive) [ 25/Aug/17 ] |
|
schwerin The Storage team feels like this was not within the original scope of the UUID project and is really a new feature extending the work that was implemented while working on UUIDs. Should this be 3.5 Required? It might also be easier for you to talk to Geert directly? |