Summary

Increase timeoutMS and blockTimeMS values in the GridFS download CSOT spec test "timeoutMS applied to entire download, not individual parts" to prevent flaky failures.

This is the same class of issue addressed by DRIVERS-2870.

Motivation

Who is the affected end user?

Driver teams implementing CSOT and running the CSOT spec test suite in CI. The current parameters (timeoutMS=75 with two blockTimeMS=50 finds) leave little headroom for driver and test infrastructure overhead across both find operations, making the test flaky.

Currently known affected driver is the Java driver.

How does this affect the end user?

This is a spec test stability change. The Java driver currently skips this test due to high flakiness.

How likely is it that this problem or use case will occur?

The failure reproduces consistently on Java driver CI, especially in TLS variants.

If the problem does occur, what are the consequences and how severe are they?

CI noise and unreliable spec coverage: false failures obscure real regressions and force drivers to skip the test.

Is this issue urgent?

No.

Is this ticket required by a downstream team?

No

Is this ticket only for tests?

Yes

Acceptance Criteria

• Update gridfs-download.yml and gridfs-download.json for the "timeoutMS applied to entire download, not individual parts" test to use:
  • blockTimeMS: 100
  • operation-level timeoutMS: 195
• Preserve semantics: total blocking time (~200ms) still exceeds timeoutMS (195ms) to reliably trigger the timeout, while providing enough headroom for normal driver overhead so the failure mode is deterministic (timeout) rather than flaky.