[SERVER-82924] Time-series collections should indicate collection UUID mismatch errors in all cases when they happen. Created: 08/Nov/23 Updated: 06/Feb/24 |
|
| Status: | Open |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Felipe Gasper | Assignee: | Haley Connelly |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | storex-ranked, time-series, time-series-mongosync | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||
| Assigned Teams: |
Storage Execution
|
||||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||||
| Sprint: | Execution Team 2024-02-19 | ||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||
| Description |
Background
We later repurposed that ticket to document a related, blocking problem where the server completely ignored collectionUUID when inserting into time-series collections. This ticket, then, “revives” Right now we mimic that pattern when we receive OperationNotSupportedInTransaction, but in order to do it we have to make a network call to fetch the updated namespace information that CollectionUUIDMismatch contains. Acceptance CriteriaThe server should always return at least an error to indicate collection UUID mismatch whenever it’s appropriate to send one, even in the presence of other errors (e.g., OperationNotSupportedInTransaction). |
| Comments |
| Comment by Felipe Gasper [ 14/Nov/23 ] |
|
I’m also realizing that the above may not match what I noted previously in |
| Comment by Felipe Gasper [ 14/Nov/23 ] |
|
Given: Time-series collection “weather”, with buckets UUID $uuidBucketsWeather. I would think it logical to flag mismatches between buckets & non-buckets collections more “loudly” than CollectionUUIDMismatch. See notes below: Operation on “weather” with $uuidSportsShould return CollectionUUIDMismatch, with current collection name = “sports”. This is the most important one for mongosync. Operation on “system.buckets.weather” with $uuidSportsThis seems like it should be a “louder” error than CollectionUUIDMismatch. Rationale: normally CollectionUUIDMismatch indicates stale client state: a rename has occurred that the client doesn’t know about. Mongosync handles this error accordingly: retry the command using the collection name that the error gives. (Or, if there’s no collection name, we understand that to be the server telling us that the collection is dropped, so we discard the event that triggered the request.) In this case, though, that behavior is inappropriate; just the fact of trying to operate on a buckets collection using a non-buckets UUID—or, trying to operate on a non-timeseries collection using a buckets collection name—indicates something more deeply wrong than just stale client state. Operation on “sports” with $uuidBucketsWeatherThis, too, seems to warrant a “louder” error that indicates non-retryability. Operation on “weather” with $uuidBucketsWeatherEven this would seem to need the “louder” error: there seems to be no good reason why a client would submit it since CRUD operations against the view will never resemble those against the buckets. |