Details
-
Bug
-
Resolution: Fixed
-
Major - P3
-
7.0.1
-
None
-
None
-
Storage Execution
-
Fully Compatible
-
ALL
-
Execution NAMR Team 2023-10-16, Execution Team 2023-10-30
Description
When I `delete` from a time-series collection with a `collectionUUID` the error is a bit strange:
db.runCommand({delete:"weather", collectionUUID: UUID("12345678-1234-1234-1234-f776a983614a"), deletes:[{ q:{ timestamp: new Date() }, limit: 0}]});
|
{
|
n: 0,
|
writeErrors: [
|
{
|
index: 0,
|
code: 361,
|
errmsg: 'Collection UUID does not match that specified',
|
db: 'test',
|
collectionUUID: new UUID("12345678-1234-1234-1234-f776a983614a"),
|
expectedCollection: 'system.buckets.weather',
|
actualCollection: null
|
}
|
],
|
ok: 1,
|
'$clusterTime': {
|
clusterTime: Timestamp({ t: 1695405156, i: 1 }),
|
signature: {
|
hash: Binary(Buffer.from("0000000000000000000000000000000000000000", "hex"), 0),
|
keyId: Long("0")
|
}
|
},
|
operationTime: Timestamp({ t: 1695405152, i: 1 })
|
}
|
Note that it says the "expectedCollection" is `system.buckets.weather`, not `weather`.
I see the same behavior with `update`.
I don't think this will cause breakage, and the `actualCollection` is correct when I give it the UUID of a real collection.
Seen in 7.0.1; it may affect other versions.
Attachments
Issue Links
- is duplicated by
-
SERVER-81433 Test time-series arbitrary updates with CollectionUUID option
-
- Closed
-
-
SERVER-81434 Test time-series arbitrary deletes with CollectionUUID option
-
- Closed
-
- related to
-
SERVER-82924 Time-series collections should indicate collection UUID mismatch errors in all cases when they happen.
-
- Open
-