You cannot trust the responses or webhooks at all.
Well... yeah. I mean it's pretty obvious, no?
Here's some things that could go wrong regardless of what care the software tries to provide:
- The transaction completed on the backend cluster but the app instance died before if could create the response and after it committed the transaction.
- The transaction completed, the app instance transmitted a response, but the load-balancer/reverse-proxy in-between died before it could relay that response.
- Everything went well, but the ISP dropped some packets before it could get to you.
- Everything completed and the ISP stayed up, but on your end the response was flagged as malicious, or never made it through your load-balancer.
So, yeah. in general when you make an API request and get an error you have to check if the state was changed anyway, and if you aren't doing that you're doing it wrong anyway and cannot blame the system on the other side for returning errors.
None of the errors you mention are what I am experiencing. Their system is creating objects but returning that it couldnt, not failing to send a response.
Some Apis are designed to always fail safe and send the correct response, or at least accept multiple messages without creating duplicates, so you can just keep firing the same message until you get the correct response.
Not doing that is just lazy design.
Those are all network errors. You wouldn't just catch all errors and treat them the same. An application error should mean the transaction did not complete.
Of course none of that applies in this case, since it's about Quickbooks. If the quickbooks api says the sky is blue, you should double check just to make sure.
Comments
Well... yeah. I mean it's pretty obvious, no?
Here's some things that could go wrong regardless of what care the software tries to provide:
- The transaction completed on the backend cluster but the app instance died before if could create the response and after it committed the transaction.
- The transaction completed, the app instance transmitted a response, but the load-balancer/reverse-proxy in-between died before it could relay that response.
- Everything went well, but the ISP dropped some packets before it could get to you.
- Everything completed and the ISP stayed up, but on your end the response was flagged as malicious, or never made it through your load-balancer.
So, yeah. in general when you make an API request and get an error you have to check if the state was changed anyway, and if you aren't doing that you're doing it wrong anyway and cannot blame the system on the other side for returning errors.
None of the errors you mention are what I am experiencing. Their system is creating objects but returning that it couldnt, not failing to send a response.
Some Apis are designed to always fail safe and send the correct response, or at least accept multiple messages without creating duplicates, so you can just keep firing the same message until you get the correct response. Not doing that is just lazy design.
Those are all network errors. You wouldn't just catch all errors and treat them the same. An application error should mean the transaction did not complete.
Of course none of that applies in this case, since it's about Quickbooks. If the quickbooks api says the sky is blue, you should double check just to make sure.