Ace Hardware, a Tricky FastManager Tax Sync, and a Real Bug Behind a Silent Outage Notification
Split between a normal Ace shift, a client's finicky accounting integration, and a bug that had been quietly eating alerts for a lot longer than anyone realized.
Ace Hardware, then straight into a client integration
Worked my usual 8:00–13:00 shift at Ace Hardware. Right after, from 13:30 to 14:00, did some work for American Laser Mark (ALM) on issues with their FastManager-to-QuickBooks Online integration: invoices weren't populating, tax was only showing up from FastManager once a field got clicked, and cash receipts recorded in FastManager weren't listing on the QuickBooks side.
Still chasing the sales tax piece specifically — FastManager has the tax calculated correctly, but QuickBooks won't add it to the invoice until you manually bump a line item's quantity and set it back, which forces a recalculation. Digging into whether that's a QuickBooks Automated Sales Tax quirk (it often doesn't recompute automatically for API-created transactions the way it does when you edit something in the browser) versus a tax-exemption or item-taxability mismatch on the QuickBooks side. More to figure out there.
Also spent 15:45–16:00 tracking down a printer that insisted it had a paper jam nobody could actually find.
A real bug behind a silent WAN-outage alert
While digging into why I hadn't been getting notified about real internet-connection problems on home-bgp, found a genuine bug in mlvpn-rs: every automatic report it was supposed to send me when the connection got bad had been silently failing since the feature was built. It was leaving out one piece of information in a way the receiving end treats as an invalid request, so the request got rejected before anyone ever saw it. Confirmed it both ways against the live service: filling in that piece gets a real ticket back, leaving it out reproduces the exact error already sitting in the logs.
The fix itself was small — just fill in that piece of information instead of leaving it out — but the real story is why it went unnoticed this long: the existing test for this only checked things inside the program itself, never actually sent the request over the network the way the real app does, so it never caught what was actually wrong. Added a new test that really sends it, the same way the real app does, so this can't quietly break again.
While in there, also gave software-support the same certificate-based admin login the rest of my sites have been getting this week, on its own address — including pointing the admin links in alert emails at that address instead of the public one, so I can click straight from an alert email into a logged-in session.