[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:
Depends
Related
related to SERVER-84151 The collMod command with non-existent... Closed
is related to SERVER-85496 createIndexes ignores collectionUUID ... Open
is related to SERVER-79446 `insert` ignores `collectionUUID` for... Closed
is related to SERVER-81379 `delete` and `update` mishandle `coll... Closed
Assigned Teams:
Storage Execution
Operating System: ALL
Sprint: Execution Team 2024-02-19
Participants:

 Description   

Background

SERVER-79446 initially reported a problem where the server prioritizes errors like OperationNotSupportedInTransaction over CollectionUUIDMismatch when failing a time-series-related request. It was considered non-blocking because mongosync can work around the quirk.

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” SERVER-79446’s original purpose: for mongosync it would be much better if the server returned CollectionUUIDMismatch when doing, e.g., a delete or update against a time-series collection, even when it’s in a transaction. This is because mongosync retries on CollectionUUIDMismatch with the correct collection name.

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 Criteria

The 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 SERVER-81379. I’m sorry for any confusion this may cause.

Comment by Felipe Gasper [ 14/Nov/23 ]

Given:

Time-series collection “weather”, with buckets UUID $uuidBucketsWeather.
Non-time-series collection “sports” with UUID $uuidSports.

I would think it logical to flag mismatches between buckets & non-buckets collections more “loudly” than CollectionUUIDMismatch. See notes below:

Operation on “weather” with $uuidSports

Should return CollectionUUIDMismatch, with current collection name = “sports”. This is the most important one for mongosync.

Operation on “system.buckets.weather” with $uuidSports

This 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 $uuidBucketsWeather

This, too, seems to warrant a “louder” error that indicates non-retryability.

Operation on “weather” with $uuidBucketsWeather

Even 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.

Generated at Thu Feb 08 06:50:41 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.