Hacker News Reader

Comment by ing33k | Hacker News Reader

Used B2 heavily until recently as a origin server for a CDN. Few weeks ago we saw a spike in 502 / 504 responses.

When I contacted their customer supported , I was pointed to the following URL where they explain in detail how they handle these errors https://www.backblaze.com/blog/b2-503-500-server-error/

Essentially they are not considered as errors and expect the client to retry loading the file. This approach won't work in our use case.

View on HN

You can definitely get read errors and your application should be aware of this and handle this use case. Amazon's own S3 is not immune to this and after years of running spark jobs which shard output across thousands of files on s3 (and load from the same) you'll see these underlying http errors on a daily scale even intra-region.

Even if you're doing multi region s3 replication you'll run into this for external clients semi-occasionally.

If you are using Cloudflare you could use a Worker script to automatically retry the origin pull and only cache it on success.

Retrying a failed network request seems like a normal thing to do -- whether its a network timeout, server error, or whatever random hiccup happened.

So, you're relying on the API being 100% reliable? no errors?

I not expecting 100 % reliability.

but when we get a 503 response it should be considered an an error and acknowledged by the provider that it's an error.

in my use case, we were using a CDN which was configured to pull files from B2. When B2 responds with a 503/500 I have no control on the retry mechanism.

The error rate was around 5-10%

Reply on news.ycombinator.com