Add an option to enable pre-defined exponential retry back-off strategy for Cloud Messaging
l-alexandrov opened this issue · comments
Describe the feature you would like to see
Summary
We need to be able to enable a retry strategy for the cases when we receive a ServerUnavailable exception and it has a retryAfter property set.
Details
FCM recommends applying an exponential back-off strategy, so it would be good to retry the request when a 503 HTTP response status is received.
It would be good to have a granular control over whether an exponential strategy is used or an equal interval, but the control over this is not mandatory.
I've seen that in the past (4.41.0) it had been possible to do this using the Guzzle's RetryMiddleware in the Guzzle configuration (#264), but this is not possible anymore.
Acceptance criteria
- Define an exponential back-off retry strategy
- Add an option to enable/disable the retrying
I'm ready to contribute and open a PR if you find this good and once I have green light from the repository owner.
Thank you for bringing this up! I removed this functionality back then because I tried to decouple the SDK from Guzzle directly where possible so that I at least could try out making the SDK HTTP Client-agnostic and because I had a feeling it wasn't used really much (my assumption is that most are not using the factory for much else than instantiating the components).
That's where the HttpClientOptions came into play. Your use case makes absolutely sense, so it would indeed be good to re-introduce the feature.
I already started extending the HttpClientOptions with new methods withGuzzleConfigOption(string $name, mixed $option) and withGuzzleMiddleware(callable ... $middleware) in a local branch that the factory could merge in when creating the API Client.
I'm currently short on time, so I cannot say when I will be able to create a PR for it, but if you want to give it a shot yourself in that fashion, I would appreciate it. Just let me know and I will either continue with it when I can find the time, or review your PR, should you decide to propose one. I have to admit that I'm not sure which one would be faster, though - it could be that I can implement it in the next few days, or not be able to review it faster, due to the same time constraint 😅
Providing a built-in option for exponential retries only would be equally fine for me, especially because it would be more "controllable" = avoid issues like "the SDK doesn't work" because a weird userland config/middleware that the issue reporter fails to mention or that breaks the SDK. What do you think?
Thanks for being on the same page with me.
I could probably suggest a PR and you could review it when you take a chance. It would be even better if I could take your branch as a base.
Could you give #799 a try? You can find the how-to at docs/setup.rst.
While this doesn't provide the explicit exponential backoff configuration, it allows extending the Guzzle Config and Middlewares at will. 🤞🏻
It looks great to me and fully addresses this issue. 🚀
Implemented with #799