Skip to content

Conversation

@peregrine-2024
Copy link

: Resolves duplicate email sending issue in osi_l10n_us_payment_nacha_email module. Prevents repeated execution of action_send_detailed_payment_emails method during export file generation that was causing duplicate bank transfer notifications. Implements unique batch payment group tracking to ensure single email delivery per payment group while maintaining support for legitimate re-sends. Addresses ticket #67591. Technical fix includes robust duplicate detection mechanism and improved email scheduling logic.

Implemented solution using Cursor CLI automation
@peregrine-2024
Copy link
Author

🛠️ Automated Fix: Prevent Duplicate Bank Transfer Email Sending

This pull request addresses Bug: Bank Transfer Email Re-Sending Multiple Times (Ticket #67591) by implementing robust safeguards to prevent duplicate email dispatches for bank transfer notifications.

🔧 Changes Overview

The primary change was made to the file:

  • osi_l10n_us_payment_nacha_email/models/account_batch_payment.py
✅ Key Additions & Modifications:
  1. New Helper Methods Added:

    • _check_emails_already_sent(batch)

      • Checks if emails have already been sent for a given batch by querying mail.message records.
      • Ensures that even if the remittance_email_sent flag is not set, duplicate sends are prevented.
    • _mark_email_sending_in_progress(batch)

      • Atomically marks a batch as “sending in progress” using a write operation.
      • Prevents race conditions where multiple triggers might attempt to send emails simultaneously.
      • Returns True if marking succeeded, False if already marked or emails were sent.
  2. Enhanced Logic in action_send_detailed_payment_emails()

    • Replaced simple flag-based check (remittance_email_sent) with a more reliable two-layer validation:
      1. Checks if emails were already sent via mail.message.
      2. Uses atomic marking to avoid concurrent execution issues.
    • Added early exit logic when no payments exist in the batch.
    • Improved error handling: resets the remittance_email_sent flag if an email cannot be sent due to missing contact info.
  3. Improved Error Handling

    • If no valid AP contact email is found, the method now resets the remittance_email_sent flag to allow re-attempts later.
    • Clearer error messages for debugging and monitoring purposes.

🧪 How It Fixes the Issue

Previously, the system relied solely on the remittance_email_sent boolean flag to determine whether to send emails. This led to duplication when:

  • The flag was not properly updated after sending.
  • Multiple processes or triggers attempted to send emails concurrently.

With these changes:

  • Emails are now checked against existing mail.message records to ensure they haven’t already been sent.
  • A locking mechanism prevents simultaneous processing of the same batch.
  • Errors during sending are handled gracefully without leaving inconsistent states.

📌 Testing & Review Notes

  • Ensure all environments (Dev, Test, Staging) are tested with batches that previously caused duplicates.
  • Verify that the new logic does not interfere with legitimate retry scenarios.
  • Confirm that mail.message tracking works correctly across different email templates and batch configurations.

This fix ensures that each bank transfer notification is sent exactly once, resolving the reported issue effectively.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

3 participants