Session: Fixes scoped session token on partition splits and multiple write endpoints enabled

[ealsur]

Mirror of Azure/azure-sdk-for-java#25555

Scenario

❕ The scenario described here does not apply if customers are manually passing session tokens as part of the RequestOptions, it only applies when users are not passing session tokens as input to operations.

When a write operation is done through the SDK instance on Session consistency, the SDK stores locally the session token in a cache and also returns the token to the user. When a read operation for the same partition is done, and the user does not pass a session token in the input, we extract the session token from the cache from the write operation and pass it along.

Since the token that travels to the Gateway and is returned is scoped to a partition, the issue arises when a partition split occurs:

1. User performs a write that is for partition 1, returns token A.
2. User performs a read for partition 1, sdk sends token A, returns token B.
3. User performs another operation for partition 1, sdk sends token B.
4. Partition 1 is split into 2 and 3.
5. Gateway returns token C for partition 2 in the response
6. SDK stores token C for partition 2.
7. User performs another operation that should map to partition 2, but because SDK has no knowledge of partition 2, it resolves to partition 1 and sends the last known token for partition 1, which is B.

Ideally on step 7, the SDK should be sending the cached token for partition 2, which is C.

Fix

To fix this scenario, we are detecting which was the resulting partition for the operation and compare that with the initial partition SDK thought it was targeting. If the partitions do not match, it triggers a refresh of the partition map. That way when Step 7 happens, the SDK is aware of partitions 2 and 3 and it would identify the operation is for partition 2 and use token C.

Additional fix

For accounts that have multiple write endpoints enabled, the cached session token was not being sent on write operations. This PR also fixes that scenario so writes contain the cached token.

Type of change

• Bug fix (non-breaking change which fixes an issue)