refactor(email-service): Contact upserting logic

[evanhutnik]

Summary

Problem

The previous implementation of contact upserting used an INSERT ... ON CONFLICT DO UPDATE pattern that would acquire row-level locks on the email_contacts table. During high-concurrency scenarios like backfilling, this led to:

• Row-level locks held for the duration of transactions
• High database session counts as connections waited for locks to be released
• Potential deadlocks when multiple transactions tried to upsert overlapping sets of contacts

Solution

Refactored the contact upsert logic to use a lock-free, optimistic approach:

1. Fetch existing contacts first (read-only, no locks)
2. Filter to only new contacts that need to be inserted
3. Insert with ON CONFLICT DO NOTHING (no row locks on existing rows)
4. Handle race conditions by re-fetching any contacts that were inserted by concurrent transactions

This approach eliminates the need for row-level locks on existing contacts and significantly reduces database contention.

• Moved contact upserting outside transactions in send/draft endpoints to prevent holding locks during long-running operations

Screenshots, GIFs, and Videos

[claude]

test

[whutchinson98]

not needed now but in the future using the non_empty crate here can help avoid those checks of

if x.is_empty() {
    return early
}