General snapshot discovery retry mechanism
Context:
In some cases a page fails to load momentarily, sometimes due to network failure or sometimes due to an unforeseen error, or resource crunch etc
In such conditions so far we reported error and dropped that snapshot - which leads to a missing snapshot warning on percy. For some customers this was more common than others.
Changes:
We now give an option under discovery section of config to retry discovery. For now its false by default
In case the retry is set to true we attempt discovery upto 3 times, printing a log line whenever its retrying the snapshot
We can also use this retry option on per snapshot basis by passing {discovery: {retry: true}} in per snapshot options.
Race condition in discovery for certain cases:
Context:
Sometimes browser requests same url multiple times in parallel. In such cases we record both as separate requests under #requests but we only get loadingFinished event for one of them. -> other request remains stuck and we throw idle timeout.
While debugging i did find that the request is infact stuck in browser - we see it in pending state. But for these requests we in general do get responseReceived callback, but dont get loadingFinished.
We need to debug further why the request is getting stuck, doesnt look like its stuck on cli.
Changes:
We are now maintaining a finishedUrls set. Whenever we look for idle we now ignore all the urls which are successfully finished at least once before.
This is okay to do as in resources we can only attach one response per url and so we dont need to have multiple response objects.
General snapshot discovery retry mechanism Context:
Changes:
discoverysection of config toretrydiscovery. For now itsfalseby defaultretryis set to true we attempt discovery upto 3 times, printing a log line whenever its retrying the snapshotretryoption on per snapshot basis by passing{discovery: {retry: true}}in per snapshot options.Race condition in discovery for certain cases: Context:
#requestsbut we only getloadingFinishedevent for one of them. -> other request remains stuck and we throw idle timeout.pendingstate. But for these requests we in general do getresponseReceivedcallback, but dont getloadingFinished.Changes:
finishedUrlsset. Whenever we look foridlewe now ignore all the urls which are successfully finished at least once before.