Add support for sending AIP-155 requestId query parameter#17259
Add support for sending AIP-155 requestId query parameter#17259wiktorn wants to merge 1 commit intoGoogleCloudPlatform:mainfrom
Conversation
|
Hi there, I'm the Modular magician. I've detected the following information about your changes: Diff reportYour PR generated some diffs in downstreams - here they are.
|
Tests analyticsTotal tests: 6343 Click here to see the affected service packages
Action takenFound 17 affected test(s) by replaying old test recordings. Starting RECORDING based on the most recent commit. Click here to see the affected tests
|
|
🟢 Tests passed during RECORDING mode: 🟢 No issues found for passed tests after REPLAYING rerun. 🔴 Tests failed during RECORDING mode: 🔴 Errors occurred during RECORDING mode. Please fix them to complete your PR. |
AIP-155 provides idempotency guarantees for clients. This PR implements client-side part, so calls to Google APIs can leverage backend capabilites.
Currently, when a request is sent and a transient network occurs, retry mechanism will send second request. While this is not a major problem when running Get or Update operations, it is a problem when sending Create or Delete request (before Long Running Operation handle is returned).
When Create operation times out or errors out with transient network error and is retried, a second call will fail with the message that object already exists and this will fail the whole operation.
Similar situation is in case of Delete operation, though there the message is that object doesn't exists.
With this change, by sending the same RequestId identifier, we oblige backend to return the same message as for original request - hence providing client-side idempotency.
Release Note Template for Downstream PRs (will be copied)
No release notes, as this should not affect the users yet, this PR just provides the capability. There will be follow-up PRs, that enable this capability for specific resources.
Selected compute resources PR: #17262