Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
@IntrusionCM I bet a hundred bugs are undetected in good codebases that retries... and they'll all be low severity issues.
-
@devphobe retry is usually the opposite of failsafe.
A simple error return with service not available, retry later would be better :)
That's all that's in most cases needed.
A simple error handler that is used when an service isn't available or the service response cannot be parsed.
It's trivial and sadly mostly neglected. -
@IntrusionCM You're not wrong. In this case a background job would (should) have failed and been requeued. Failsafe logic is different (and better)
-
@sam94 s/appalling/appealing/
A personal memo to all developers on devRant:
* Assume every external line of code, (including every service you consume) is an unreliable crock of flaming shit. These services can and will fail in the most glorious ways. Write your code to be resilient, and ASSUME FAILURE of dependencies. Even if it's your own team writing the other service.
Heard in a meeting today: "Your team's service outage is going to cause my service to corrupt the database!"
Response I wanted to give: "No, you asshat, my service outage is a normal part of living with microservices. Your app should have been smart enough to recognize the failure."
rant
database-down
service-down
developer-down