Re-request errored tiles with exponential back off

[andrewharvey]

mapbox-gl-js version: master

Almost opposite to #1551, if a tile request returns a 5xx status code, should there be an exponential backoff to re-requesting it?

Related to the work you've been doing with respect to tile expiry @lbud?

[tgecho]

This would be extremely helpful. For example, right now mapbox will cache an error response until the tile comes into view again, even if the error response includes explicit caching headers or even a status code of 503 with a Retry-After header.

[fergonco]

Another scenario where this would be useful: we catch 401 status codes on the "error" event handler and reauthenticate silently. The requested tiles, however, are not retried and the map will just not show a layer the user has access to for no apparent reason. After some interaction with the map the tiles will be retried and everything would work as expected.

I would add that in my case just a method to retry failed tiles (instead of a back off) would fit quite well.

[WernerMairl]

+1 for re-request, with "Retry-After"

usecase: I'm hosting a TileServer where vector tiles are calculated on the fly... sometimes (cold-cache) it takes longer then the timeouts....

[vladkasianenko]

Any news on this?

P.S. Maybe it should be some kind of method that would wait for a custom logic to complete before re-requesting the tiles one more time.

Or it might be something like this:

this.map.on('error', (e) => {
  // do some logic here
  this.map.requestFailedTiles();
 // or...
 this.map.failedTiles.request();
});

[ivan-palatov]

Any news on this? It would be really great to have controll over the requests, especially for error handling and retrying