-
Notifications
You must be signed in to change notification settings - Fork 107
fix: truncate RPC timeouts to time remaining in totalTimeout #1191
Changes from all commits
42a113f
9aea1ba
10f9f84
cb8a7d5
dcbf828
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -94,11 +94,14 @@ public class OperationCallableImplTest { | |
.setInitialRetryDelay(Duration.ofMillis(1L)) | ||
.setRetryDelayMultiplier(1) | ||
.setMaxRetryDelay(Duration.ofMillis(1L)) | ||
.setInitialRpcTimeout(Duration.ZERO) // supposed to be ignored | ||
.setInitialRpcTimeout( | ||
Duration.ZERO) // supposed to be ignored, but are not actually, so we set to zero | ||
.setMaxAttempts(0) | ||
.setJittered(false) | ||
.setRpcTimeoutMultiplier(1) // supposed to be ignored | ||
.setMaxRpcTimeout(Duration.ZERO) // supposed to be ignored | ||
.setRpcTimeoutMultiplier( | ||
1) // supposed to be ignored, but are not actually, so we set to one | ||
.setMaxRpcTimeout( | ||
Duration.ZERO) // supposed to be ignored, but are not actually, so we set to zero | ||
.setTotalTimeout(Duration.ofMillis(5L)) | ||
.build(); | ||
|
||
|
@@ -475,9 +478,16 @@ public void testFutureCallPollRPCTimeout() throws Exception { | |
OperationTimedPollAlgorithm.create( | ||
FAST_RECHECKING_SETTINGS | ||
.toBuilder() | ||
// Update the polling algorithm to set per-RPC timeouts instead of the default zero. | ||
// | ||
// This is non-standard, as these fields have been documented as "should be ignored" | ||
// for LRO polling. They are not actually ignored in code, so they changing them | ||
// here has an actual affect. This test verifies that they work as such, but in | ||
// practice generated clients set the RPC timeouts to 0 to be ignored. | ||
.setInitialRpcTimeout(Duration.ofMillis(100)) | ||
.setMaxRpcTimeout(Duration.ofSeconds(1)) | ||
.setRpcTimeoutMultiplier(2) | ||
.setTotalTimeout(Duration.ofSeconds(5L)) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What is the meaning of totalTimeout in case of LRO? Note that exponential retry algorithm is shared between retries and LRO polling logic. Whatever we do for retries, we must ensure that it does not break LRO. Ideally we want that new logic be completelly disabled fro LRO. I.e. the need to modify LRO tests indicates that there is a breaking behavioral change for LRO, which we should avoid. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I had the same thought and I was confused by what this test was doing. The test setup actually sets by default a There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. FWIW we had no GAPIC config for LRO polling There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I guess this test was testing for the existing incorrect behavior, where the RPC timeout didn't care if it exceeded the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The This test was set up weirdly, as I described. PTAL. |
||
.build(), | ||
clock); | ||
callSettings = callSettings.toBuilder().setPollingAlgorithm(pollingAlgorithm).build(); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What would happen if
newRpcTimeout <= 0
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If
newRpcTimeout <= 0
, the subsequent check byshouldRetry
would prevent another attempt from being made, because they do a similar check to see if the current time + the proposed random delay would exceed thetotalTimeout
:We could add some logic to handle
if (timeLeft.isNegative() || timeLeft.isZero())
, but I'm not sure what we'd set it to...maybe allownewRpcTimeout
to remain unchanged bytimeLeft
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After our offline conversation, I've decided to just document the likely behavior. LMK if you feel strongly otherwise.