I'm a little nervous about changing the default behavior from 60s to 5s for the initial request. Prior to the change that resulted in unexpected backoff behavior, what was the initial value? If it was 5, this could be considered a return to the "correct" value, but if this is the first time we are introducing it as 5, I fear we could break behavior for people.

Prior to the change that resulted in unexpected backoff behavior, what was the initial value?

Initial value = 60s

Pre api_core change:

initial RPC value = 60s
retry RPC value = 60s
total timeout across retries = 600s

Post api_core change:

initial RPC value = 60s
retry RPC value = 0s
total timeout across retries = 600s

Post this PR:

Initial RPC value = 5s
retry RPC value = [5, 60] with multiplier=1.3
total timeout across retries = 600s

but if this is the first time we are introducing it as 5, I fear we could break behavior for people.

• This is the first time we have 5s as the initial RPC value and yes, this is a breaking change.
• Hypothetically, even if the initial value was 5s(it isn't), then changed to 60s in 2022, I'm not sure how much weight we must give to the fact that it was 5s initially, since its been a few years with this new behavior, i.e, this would still be a breaking change for those who onboarded between 2022 and now.

Code / Links for easy reference

• Both pre and post api_core change, we passed in default_timeout=60 from Pub/Sub to api_core library.
• Pre api_core change, this was interpreted as ConstantTimeout(60)
• Post api_core change, this is interpreted as TimeToDeadlineTimeout(60)
• This interpretation of default_timeout=60.0 in api_core happens here
• Post PR change, timeout decorator applied would be ExponentialTimeout instead of TimeToDeadlineTimeout(60)
• Definition of different timeout options can be found here