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

fix: client no longer delays when it wont retry #51

Merged
merged 2 commits into from
Sep 13, 2024

Conversation

graceannx
Copy link
Contributor

Description

In the retry function, delay was firing without hitting retry, resulting in increased response times. We modified the function to only delay when the retry occurs.

Motivation and Context

Jira ticket

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

  • My code follows the code style of this project.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have read the CONTRIBUTING document.
  • I have added tests to cover my changes.
  • All new and existing tests passed.

@graceannx graceannx requested a review from a team as a code owner September 13, 2024 11:34
@@ -360,7 +360,7 @@ function retry(fn, ctx) {
function attempt(i) {
return fn(ctx)
.catch((err) => {
if (maxAttempts > 0) {
if (i < maxAttempts && isCriticalError(err) && ctx.retryDelay && ctx.retryDelay > 0) {
Copy link

@szpytfire-bbc szpytfire-bbc Sep 13, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder whether it's worth leaving a comment explaining the rationale here? Perhaps even something as simple as (just so that you can take a quick glance at the code and understand what it does straight away):

// Only critical errors should retry

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah agree with this

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Re: critical errors. In this instance isn't it clear from the code that that's the case?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cjewell47 there are a lot of other conditions chained in the if statement, but none of them matter unless the error is critical (which I think is the main fix/change in this PR). The comment would just highlight that importance, so that someone new to the code takes note 😃

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks guys, we have added some jsdoc to make this a bit clearer

Copy link
Contributor

@vaughan-rich vaughan-rich left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great spot - lgtm. I guess on Monday / whenever this goes through and gets bumped, we should remove all empty category forms in iSite just so:

  • we prove that this fixes things
  • there are only category forms in iSite that are actually being used

@graceannx graceannx merged commit 5958210 into main Sep 13, 2024
@simongregory simongregory deleted the IPLAYER-45275-Cache-Response-Times branch September 13, 2024 13:36
@sbason
Copy link
Contributor

sbason commented Sep 13, 2024

Can we please have some tests added for this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants