Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
Root797347y@ClemFrieckie yes, but that doesn't tell me how it's called.
Ex: the controller calls a function via an `after_save` trigger, which calls method on a model, which calls another method on a different model, which may have another trigger, and that calls something that sends an email.
If I find the code that sends an email, working backwards is still quite difficult. -
hjk10156967y@Root we used to have the same problem with scheduled tasks. Running on different servers. Sometimes in the applications own scheduler sometimes in etc/cron* files and sometimes in the users crontab. Now we have everything nicely organized in rundeck.
You could try and trace it backwards. Create a dummy signup and see if you get something. Check the servers maillog. If it's not there check the received mail headers to figure out what service is used. Search the code for the appropriate API calls. If you find only a generalized mail method you can see either where it's called of use a debugger and it's call stack feature. -
Perhaps you could run your services in an sandbox with all connections, only no connection to the mailserver and look for an exception thrown if it couldn't connect to the mailserver.
There you can get to line and stacktrace of the call -
Root797347y@hjk101 @realLifeMock Both are great ideas! However, I decided to simply ask the accountants if they send an email manually, and if not, to sign up and promote a customer with valid email, and forward me any confirmation email they receive.
Doesn't show me where or how it happens, but does tell me *if* it happens. I can then work backwards from the email template.
Total time investment: 30 seconds ^^ -
hjk10156967y@Root so you only need confirmation that a mail is send I thought you needed to know all the business rules and perhaps modify the code.
Asking someone who knows always trump's investigation 😁 -
Root797347y@hjk101 I absolutely will at some point. However, all I will need to do in the near future is modify whatever email we send -- or write one if we do not.
I have more than enough other tasks to keep me busy.
(... including trying to figure out how the company is still alive, and if it's even solvent. :/)
Related Rants
The bossman asked if our signup service sends an automated email after we successfully process someone's payment or when we promote them to full customer.
That sounds like a simple query, yeah?
Well.
Here's some background:
We have four applications; one in React, three in Rails. I'll replace their names to retain some anonymity.
1) "IceSkate" is the React app, and it's a glorified signup form. (I wrote this one.)
2) "Bogan" is the main application, and is API-only; its frontend has been long since deprecated by the following two:
3) "Bum" is a fork of "Bogan" that has long since diverged. It now contains admin-only tools.
4) "Kulkuri" is also a fork of "Bogan" that has long since diverged. It now contains tools specifically for customers, which they can access.
All but IceSkate (obv) share a database.
Here's how signups happen:
Signups come in from IceSkate, which hits a backend API on Bogan. Bogan writes the data to the database, charges the card immediately, and leaves the signup for moderation.
And here's how promotion from signup to customer happens:
Bum has a view allowing admins to validate, modify, and "promote" a signup to a full customer. Upon successful promotion, Bum calls "ServerWrap", a module which calls actions on the other applications; in this case: Bogan.
Bogan routes execution through three separate models before calling "ServerWrap" again, this time calling KulKuri.
Finally, KulKuri actually creates the customer!
After KulKuri finishes creating the customer, execution resumes on Bogan, which then returns, causing execution to resume on Bum. Bum then runs through several other models, references the newly-created customer object (as all three share a database), and ... updates the customer with its current data, and then updates the signup object. After all of this, it finally shows the admin the "new customer" view.
It took me 25 minutes to follow the chain of calls, and I still don't know quite what's going on. I have no idea if any of it sends an email or not -- I didn't see any signs of this, but I very easily could have overlooked something.
So, to answer bossman's question... I asked the accounting people if they send the email manually. If they don't, it's automatic, which means I missed something and get to burrow through that mess all over again!
I really hope I missed something; otherwise I need to figure out how and where (and when!) to send the email...
just...
errrrgghh
undefined
epic spaghetti