Comment by alt227
10 hours ago
I had the exact same thing with the Quickbooks api recently. You cannot trust the responses or webhooks at all.
On create a user or invoice for example sometimes it will return an error, yet it actually created the entity. This means you have to check manually after creating everything to know if its created properly.
Then you have the issue that sometimes quickbooks takes a while to update, and locks the company file while it does some background magic. This means you cannot immediately do the existence check, and also sometimes the check errors or times out which essentially means you need to keep checking forever until you can properly reconcile your db against theirs. But with hundreds/thousands of transactions per minute this state is never reached. You perpetually live in a state of trying to catch up but never managing it.
When I brought it up with Quickbooks dev support their response was literally "Its your job to make sure things are created properly in our system".
How did we get to this place where we started putting up with systems that cannot ever be trusted?
That is the way enterprise software works as a system. It demands to be the central focus of everything. Workers want to route around these turbo productivity theater nonsense that could be replaced by a few K script that gates access to a text file and checks validity of appends. That can’t be allowed, so you need what is essentially whole poorly documented OSs to enable an economy of brokers to it, or the whole con would collapse.
> 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.
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.