Suggestion: use 404 and 429 in the UUID API to match the slug API about healthchecks HOT 4 CLOSED

Thanks, that's a good idea, added the Retry-After header for 429 responses.

from healthchecks.

Thanks for the suggestion! The UUID URLs on the hosted service have been returning HTTP 200 from the start, and I don't think I can change that behavior now, this would risk breaking existing setups.

When I was implementing slug URLs, I changed the logic to also return 404 and 429 status codes. No-one was using the slug URLs yet, so there was no problem changing the behavior.

I had a quick look at favonia/cloudflare-ddns#239. The HTTP client would not retry HTTP 200 status codes, but perhaps that's not a huge problem?

• If a check with a particular UUID does not exist, there's no point retrying it – it is unlikely to come into existence on retry
• If the HTTP client hits a rate limit, this means the client is pinging too often. It should ping less often instead of retrying even more!

(though I agree, it would be better to return 404 and 429, so the client knows what's up and can make intelligent decisions, instead of returning 200 and tricking client into thinking everything's OK)

from healthchecks.

@cuu508 Thanks for checking all of these. You are absolutely right. It was my perfectionism preventing the (practical) unification of all retry logic. For the code 429 though, have you considered sending a Retry-After HTTP header? This should prevent (good) clients from pinging too much.

from healthchecks.

I am closing this because there are no more actionable items. I took your advice and refactored my code. Thank you again for your time.

from healthchecks.