2025-03-17 20:58:26 +01:00

153 lines
4.6 KiB
YAML

description: "timeoutMS behaves correctly for GridFS delete operations"
schemaVersion: "1.9"
runOnRequirements:
- minServerVersion: "4.4"
serverless: forbid # GridFS ops can be slow on serverless.
createEntities:
- client:
id: &failPointClient failPointClient
useMultipleMongoses: false
- client:
id: &client client
uriOptions:
timeoutMS: 75
useMultipleMongoses: false
observeEvents:
- commandStartedEvent
- database:
id: &database database
client: *client
databaseName: &databaseName test
- bucket:
id: &bucket bucket
database: *database
- collection:
id: &filesCollection filesCollection
database: *database
collectionName: &filesCollectionName fs.files
- collection:
id: &chunksCollection chunksCollection
database: *database
collectionName: &chunksCollectionName fs.chunks
initialData:
- collectionName: *filesCollectionName
databaseName: *databaseName
documents:
- _id: &fileDocumentId { $oid: "000000000000000000000005" }
length: 8
chunkSize: 4
uploadDate: { $date: "1970-01-01T00:00:00.000Z" }
filename: "length-8"
contentType: "application/octet-stream"
aliases: []
metadata: {}
- collectionName: *chunksCollectionName
databaseName: *databaseName
documents:
- _id: { $oid: "000000000000000000000005" }
files_id: *fileDocumentId
n: 0
data: { $binary: { base64: "ESIzRA==", subType: "00" } } # hex: 11223344
- _id: { $oid: "000000000000000000000006" }
files_id: *fileDocumentId
n: 1
data: { $binary: { base64: "ESIzRA==", subType: "00" } } # hex: 11223344
tests:
- description: "timeoutMS can be overridden for delete"
operations:
- name: failPoint
object: testRunner
arguments:
client: *failPointClient
failPoint:
configureFailPoint: failCommand
mode: { times: 1 }
data:
failCommands: ["delete"]
blockConnection: true
blockTimeMS: 100
- name: delete
object: *bucket
arguments:
id: *fileDocumentId
timeoutMS: 1000 # The client timeoutMS is 75ms and the operation blocks for 100ms, so 1000ms should let it succeed.
- description: "timeoutMS applied to delete against the files collection"
operations:
- name: failPoint
object: testRunner
arguments:
client: *failPointClient
failPoint:
configureFailPoint: failCommand
mode: { times: 1 }
data:
failCommands: ["delete"]
blockConnection: true
blockTimeMS: 100
- name: delete
object: *bucket
arguments:
id: *fileDocumentId
expectError:
isTimeoutError: true
expectEvents:
- client: *client
events:
- commandStartedEvent:
commandName: delete
databaseName: *databaseName
command:
delete: *filesCollectionName
maxTimeMS: { $$type: ["int", "long"] }
- description: "timeoutMS applied to delete against the chunks collection"
operations:
- name: failPoint
object: testRunner
arguments:
client: *failPointClient
failPoint:
configureFailPoint: failCommand
mode:
# The first "delete" will be against the files collection, so we skip it.
skip: 1
data:
failCommands: ["delete"]
blockConnection: true
blockTimeMS: 100
- name: delete
object: *bucket
arguments:
id: *fileDocumentId
expectError:
isTimeoutError: true
# Test that drivers are not refreshing the timeout between commands. We test this by blocking both "delete" commands
# for 50ms each. The delete should inherit timeoutMS=75 from the client/database and the server takes over 75ms
# total, so the operation should fail.
- description: "timeoutMS applied to entire delete, not individual parts"
operations:
- name: failPoint
object: testRunner
arguments:
client: *failPointClient
failPoint:
configureFailPoint: failCommand
mode: { times: 2 }
data:
failCommands: ["delete"]
blockConnection: true
blockTimeMS: 50
- name: delete
object: *bucket
arguments:
id: *fileDocumentId
expectError:
isTimeoutError: true