Summary

The OIDC reauthentication tests only send a 391 on the first command of an operation, so a driver that doesn't reauthenticate when a 391 comes back on getMore or killCursors (as in GODRIVER-4187, which breaks cursors open when a GCP Workload Identity token expires) still passes.

Motivation

Who is the affected end user?

Users using GCP WI

How does this affect the end user?

If other drivers have a bug similar to GODRIVER-4187, cursor iteration can fail partway through with ReauthenticationRequired when the OIDC token expires, because the driver doesn't reauthenticate on getMore.

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

Unclear

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

Require read retries at the application

Is this issue urgent?

No

Is this ticket required by a downstream team?

No

Is this ticket only for tests?

Yes.

Acceptance Criteria

Need a test that asserts the following:

This test differ from DRIVERS-3195 as that solution does not test killCursor or getMore for OIDC. Here are the Go driver prose test, perhaps they can be used as a template:

• getMore: https://github.com/mongodb/mongo-go-driver/pull/2675/changes#diff-1d39ec86315e1d7374f2988ccc22aa14d201d6a2d4e076e67cf2d42dcee48b72R682
• killCursors: https://github.com/mongodb/mongo-go-driver/pull/2675/changes#diff-1d39ec86315e1d7374f2988ccc22aa14d201d6a2d4e076e67cf2d42dcee48b72R744