-
Notifications
You must be signed in to change notification settings - Fork 370
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Improve] Handle HTTP header Retry-After from responses from OneSignal #2064
[Improve] Handle HTTP header Retry-After from responses from OneSignal #2064
Conversation
f38d522
to
533d321
Compare
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.
I had a hard time keeping in my head for all the variables what are in milliseconds and what are in seconds.
Edit - yup, removed the comments, I just re-read those and messed myself up
@@ -37,6 +37,11 @@ class ExecutionResponse( | |||
* When specified, any operations that should be prepended to the operation repo. | |||
*/ | |||
val operations: List<Operation>? = null, | |||
/** | |||
* Optional Integer value maybe returned from the backend. | |||
* Any future requests by this time. |
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.
nit - is this missing first part of "The module handing this should delay any future requests by this time."
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.
ah good catch, just fixed this with a git commit --fixup
and then did a git rebase --autosquash
to keep the commits clean. New commit is 0e1f4a9
@@ -12,4 +12,9 @@ class BackendException( | |||
* The response, if one exists. | |||
*/ | |||
val response: String? = null, | |||
/** | |||
* Optional Integer value maybe returned from the backend. | |||
* Any future requests by this time. |
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.
nit - is this missing first part of "The module handing this should delay any future requests by this time."
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.
ah good catch, just fixed this with a git commit --fixup
and then did a git rebase --autosquash
to keep the commits clean. New commit is 0e1f4a9
I confused myself with seconds and milliseconds. Approved now! |
Add all the framework to parse Retry-After from the HTTP client layer, through to the code calling it, to the OperationRepo. This commit doesn't change any of the logic yet, but gets everything in place before making behavior changes and adding the tests.
The real getHeaderField supports returning null when the key is not set. Correcting this fixes failing HTTPClientTest
Use the retryAfterSeconds to stall processing in the OperationRepo. We wait in the OperationRepo as this allows more operations to be grouped together, as we getGroupableOperations will be called after the delay. There are number of other places that use HTTPClient other than the OperationRepo, we will address those in a follow up commit.
When we get a Retry-After we delay all future requests until after this time as passed. To be safe we assume the server's Retry-After value means all traffic should be delayed until then. If we wanted finer grain control we could work with the the backend to decide which endpoints should be affected.
533d321
to
0a8684b
Compare
Description
One Line Summary
Respect standard HTTP Retry-After header from any responses from OneSignal's backend.
Details
Motivation
When OneSignal's backend is under heavy load they want to be able to throttle back requests to them.
Scope
Only effects delaying follow up network requests after we receive
Retry-After
in a response. IfOpeartionRepo
triggers this then it handles this smartly by delaying future requests, so more batching can be done. Other code that depends on theHttpClient
simply delays requests to respect this header.Testing
Unit testing
Added and updated a number of Unit tests. OperationRepo, it's executors, and HttpClientTests.
Manual testing
Tested on Android 14 emulator. Ensured we correctly handled 429 with it's
Retry-After
by doing the following.429
Affected code checklist
Checklist
Overview
Testing
Final pass
This change is