Skip to content
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

Merged
merged 5 commits into from
May 1, 2024

Commits on Apr 30, 2024

  1. Retry-After mapping to internal retryAfterSeconds

    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.
    jkasten2 committed Apr 30, 2024
    Configuration menu
    Copy the full SHA
    0e1f4a9 View commit details
    Browse the repository at this point in the history
  2. fix incorrect getHeaderField null mocking

    The real getHeaderField supports returning null when the key is not set.
    Correcting this fixes failing HTTPClientTest
    jkasten2 committed Apr 30, 2024
    Configuration menu
    Copy the full SHA
    71c4960 View commit details
    Browse the repository at this point in the history
  3. use the retryAfterSeconds in OperationRepo

    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.
    jkasten2 committed Apr 30, 2024
    Configuration menu
    Copy the full SHA
    3041c52 View commit details
    Browse the repository at this point in the history
  4. Configuration menu
    Copy the full SHA
    08e5e83 View commit details
    Browse the repository at this point in the history
  5. delay OneSignal network requests if Retry-After

    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.
    jkasten2 committed Apr 30, 2024
    Configuration menu
    Copy the full SHA
    0a8684b View commit details
    Browse the repository at this point in the history