So, we discovered many of the leads originating from LoanappGenius weren’t making it to our application. A previously mentioned contractor decided that if a lead funneling in from LoanappGenius (LG) did not transmit to a client’s FG LOS correctly, a cron would try again five minutes later.
What’s happening?
With any application, things can go wrong: wires get crossed, resources go down, devious edge cases crop up. With LG, things do go wrong. All the time:
- A misplaced character in some configuration does not gracefully fail or at least make some reasonable guess
- Some completely obscure field mapping loses the index of the view it’s meant to appear on (don’t ask)
- The database was, ahem, poorly implemented
All of this to say that for many loans, something breaks, and the cron tries to resend the lead every five minutes until the end of time or ten thousand eternal years, whichever takes longer. It also sends emails on a chain when it fails.
Get dirty
I start by interpreting mysterious and ambiguous error status codes. Then I make that tough call to add some code that prevents sending leads to the client’s FG LOS for those clients that do not have an FG LOS.
I tried getting cheeky and catching obvious XML build errors in LG before they were sent, but it seems PHP’s XML parsing libraries aren’t exactly made for that, at least as compared to the python application and it’s minidom lib that receives the XML.
I add some necessary validation on the sending side. This further propagates some bad practices occurring on LG, but I make it give the proper warnings, and sometimes what can you do? This helps to repair and salvage any existing leads and prevents future breakage.
Finally I code the functionality that allows admin users the ability to unstick broken leads by deleting them via a manage submissions page.
Future headaches are averted.