Re^2: Async HTTP(S) client

[cavac]

Just for reference: I hardly ever call code "garbage". But this is code that does (or is supposed to) run debit card transactions. I can't post it here (closed source), but the following problems have been observed in prodution systems:

• Timeout mismatches. The code marks transactions as failed even when they went through, with the effect that debit cards were double charged.
• Transactions that don't time out at all, forcing the user to restart the cash register.
• Working on the wrong transaction, with the effect that the customer gets charged the incorrect amount.
• No handling of child process exits, leading, again to forcing the user to restart the cash register.
• Not restart safe. Restarting the cash register (reboot, power loss, etc) while a transaction is in progress can lead, again, to the process working on the wrong transaction, charging the customer the wrong amount.
• A temporary connection loss of connection to the cloud server of the debit terminal provider again can lead to the transaction marked as failed (when it was processed successfully on the provider side), potentially leading to again double charge the customer.

In many cases i can be somewhat lenient about bugs. And as long as the software just crashes and can cleanly restart, nothing will go wrong - this case is already handled by my service manager software. Not good, but we are taking about a downtime of a couple of seconds of a background service, something the user will hardly notice if at all.

But when you are developing software that is dealing with other peoples money (in our case, the customers of our customers), "move fast and break things" is absolutely in no way acceptable. It has to work. Perfectly. Each and every time.

If there is a chance greater than one in a million transactions that a specific error happens, the software needs to handle that error correctly. After all, for busy shops such a "rare" error would at least happen every couple of years. Multiply that by a large number of customers. It's the curse of scaling. And it can easily turn into a PR nightmare, especially since people are trusting that their debit and credit card transactions just work. And, oh, if the problem keeps happening, one can easily loose certification by the debit/credit card terminal provider, which is an even bigger quantum leap in "oh shiiiiiit!".

In cases of critical code like this, frankly, one small bug is a disaster. Multiple large bugs that amplify each other is what made me declare that piece of code "garbage".

[Anonymous Monk]

that adresses exactly zero of the questions raised

[cavac]

who's going to maintain your reinvented wheel

That is exactly the same question i have. For all modules, both the ones developed in house and the ones maintained by a third party that i just download from CPAN.

and will they end up calling your code "garbage" too?

Maybe? But that hasn't happened in the last decade or so.

Mojo::UserAgent

No. It doesn't fit into the way my cyclic executives are designed (which i have used in producion code for 15+ years).

And Mojo::UserAgent has an astonishingly ugly syntax, looks like JavaScript. Yes, i develop in JS, too, and yes, i am forced to use Promises, and yes that's also an ugly syntax.

Happy?

[Anonymous Monk]

Happy?

No, because the point was to try and push you towards showing or gaining some insight of the issues with your attitude and approach. In your post you basically said "I don't trust others code, it wouldn't work anyway, plus did I mention it's ugly too?" No one said your code was garbage, you could write the most beautiful and functional code, but it would still be a reinvented wheel. We're not talking about some custom protocol here, this is a HTTP client, CPAN is already littered with the corpses of unmaintained, buggy, reinvented HTTP clients. The harsh realtiy is that even if you release it to CPAN, most likely you'll be the only user of that module, everyone else will continue to use the de facto standard modules that already exist and are used in all the tutorials out there and that have communities and are already maintained. That means that when you're no longer around to maintain your code, someone else will have to take over and maintain your business-critical reinvented wheel, and chances are good that they will curse you for not using a standard off the shelf module no matter how good your code is. If you just wanted to show off some cool code you wrote that'd be one thing, but then you explained this is production level payment handling code. Sorry, but your time is better spent on figuring out how to refactor your existing code base to plug in one of the existing modules.

</rant>