Retry loading a file

[rarkins]

I've been logging error callbacks from loadjs for the past 5 weeks. My observations are:

• Mobile devices make up about 80% of the errors, although only around 50% of the users
  • Makes sense as mobile more likely to be lossy
• For each user impacted, there's an average of 2 errors each
  • This despite each page loading an average of about 8 files through loadjs, i.e. it's not even close to 100% of files being impacted at once - the rest presumably got through

This leads me to believe that in some of these cases, retrying failed file loads might actually work. Although I could probably write a wrapper around this, would you support the concept of retries in the library itself?

[rarkins]

Cc @amorey

[amorey]

@rarkins Nice work! It's useful to get a sense of why the errors are actually occurring. I think we can add a numRetries option without adding too many bytes to the script. Do you want to take a stab at it?

[rarkins]

@amorey yes, I'll take a look at the source code

[amorey]

@rarkins I added a numRetries option to loadjs in v3.1.0:

loadjs(['/path/to/foo.js', '/path/to/bar.js'], 'foobar', {
  success: function() { /* foo.js & bar.js loaded */ },
  error: function(pathsNotFound) { /* at least one path didn't load */ },
  numRetries: 2
});

Let me know if you run into any issues using the feature.

[rarkins]

@amorey thanks for adding this. Can you tell me if my understanding is correct?

• If numRetries is absent then default behaviour is assumed, i.e. 1 attempt and 0 retries
• If numRetries is 2 like in your example, then it will try up to 3 times in total (first attempt and then 2 retries)
• The error callback will be called after all retries have failed, e.g. after 3 attempts in your example

?

[amorey]

@rarkins That's correct:

• The default value of numRetries is 0 so if it is absent then there will be 1 attempt and 0 retries.
• If numRetries is 2 then it will try up to 3 times in total
• The error callback will be called after all retries have failed

Initially I had chosen the name numTries but I thought your suggestion of numRetries made the retry behavior more explicit. Let me know if you think numTries would be better or if you have any other suggestions!

[rarkins]

@amorey I think that numRetries is fine - I was just wanting to double check we had the same understanding of terminology

[rarkins]

I tested this in development and experimented with blocking dependencies using a browser plugin. I verified:

• Number of attempts is as expected
• Success and Error callbacks are still being triggered as expected

I couldn't work out a way to truly simulate a bad network and block a dependency 1 or 2 times before allowing it to succeed.

Anyway, I will push this to production shortly and let you know if I can observe anything after a while. Lately it's been pretty good with < 1% of users reporting network errors (assuming such reports to my analytics aren't lost or blocked!).

Thanks again for solving this.

[amorey]

Great! Thanks for checking the code with the browser plugin. Let me know if the new code decreases the number of network errors you're seeing.