Aaryan Bhagat writes:
In the case of
Send_Warningsfunction if the same approach was followed, meaning it would take one by one the
Addressinstances, check tuples in the
bounce_infoattribute ( see the pr for this ) and see whether to send a warning mail or not to can be a slow method.
Let's suppose the
Addresseslist is very long, then an
Addressinstance in the very bottom of the list whose subscription has been disabled and some warning emails send, now waits to receive another mail as the interval is more than
If the function is enumerating from the top then in order to take action first it has to reach this
Addressinstance but the interval is already crossed. This can cause slow performance as the
warning mailwill be sent way late than it actually should have been sent.
I assume that what you mean here is that this process is executed perhaps once per day and probably takes a few minutes at most in processing. Then we have 300s/86400s = 1/288 of a day = probability that during the interval that address's timer expires, and the message is delayed until the process triggers again, hypothetically a full day.
The odds that this happens is quite small unless you have a humongous list. Furthermore, the probability that the mail will go through this time if the account has disabled due to bouncing is presumably way less than 1. So my first-order response is this is a non-problem.
Note that you have basically the same problem if the Address's timer expires a few seconds after the send_warnings process finishes.
My second-order response is if you still care given that this is
rarely going to happen, and even more rarely will it generate a
message that reaches the user who reactivates the subscription, you
can arrange to have an index on the Addresses (or a separate queue)
which has the earliest timer first, and then process the Addresses in
that order. You'll still have the same problem if the timer expires a
few picoseconds after you start processing the particular address. :-)
Basically the way to deal with this is to adjust the
If you do implement the queue, another possibility comes up, which is that you process the queue continuously, with a process (a runner, I guess) that sleeps until it's time to process the next send_warning. This would have the advantage that if there were another "DMARC event" that caused large number of bounces, you wouldn't have a flood of warning messages are a particular time of day.
- Also if I am implementing 2 functions
send_warningswhat if both of them attempted at the same
What about it? This is even more unlikely, and I assume that process_bounces will have a read-write lock that prevents reading (and writing) while it's writing, while send_warnings will have a read lock that prevents writing while it's reading. I think all of the databases we support have such locks.