Summary

In the OIDC spec, to prevent unintentional expiry of a valid cache, we introduced a mechanism that allows us to check if a connection "has" an expired Access Token. Using this mechanism, we can, in a non-blocking way, check if a command will fail prior to sending it. The spec requires error-handling logic around the "sending of the command", to retry the command after reauth if the command fails (due to that expired Access Token). A pre-emptive check can be placed prior to sending the command, instead of sending the command and waiting for it to fail, and then re-sending.

Without this pre-emptive check, every time an Access Token expires, all connections will unnecessarily fail their next command (and then retry and succeed).  

Motivation

Who is the affected end user?

OIDC users.

How does this affect the end user?

Unnecessary command failures. Spec elsewhere makes effort to avoid excess round-trips (speculative auth, etc.).

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

Main path.

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

Perf concern.

Is this issue urgent?

Ideally addressed as part of original OIDC work, since it appears to be a trivial fix (few lines of code).

Is this ticket required by a downstream team?

-

Is this ticket only for tests?

not tests

Acceptance Criteria

Spec contains wording equivalent to: "Drivers must perform a pre-emptive, non-blocking check to see if the Connection's Access Token is expired. If it is, they must reauthenticate prior to performing the operation, rather than only after the operation has failed due to a 391." (The spec must still require reauth after a 391, since the token can expire on the server without the driver yet knowing.) Spec has a test that exercises the above.