Notification Sent to Wrong User

An order confirmation email for order 501 is delivered to user-b@example.com instead of the order owner user-a@example.com. The notification service resolves the recipient's email address from an in-memory cache that still holds user-b's address from a previous lookup. Because the cache is not invalidated when a user updates their email, stale address data is used for outgoing notifications.

HighIntermediateManual testingAPI testingExploratory testing

// UNDERSTAND

// Symptoms

User-b@example.com receives an order confirmation email for order 501, which belongs to user-a@example.com
User-a@example.com does not receive a confirmation for their own order
The email body contains the correct order details (order 501, user-a's items) but is addressed to user-b's email
The bug surfaces only for users who changed their email address recently — users whose address is freshly cached are unaffected
Delivery logs show the email was dispatched to user-b@example.com, not user-a@example.com

// Root Cause

The notification service resolves recipient email addresses from an in-memory LRU cache keyed on user ID. The cache is populated on first lookup and never invalidated on email address change. When user-b's address was cached first, a subsequent request for user-a's address (with the same user ID slot in the cache, or after a cache collision) returns user-b's stale address
The fan-out job resolves recipient addresses in batch using a snapshot of user IDs captured at job creation time, but it reads email addresses from an in-memory map built at service startup — changes made after the service started are invisible to the map, causing notifications to be sent to the address that was current when the service last restarted

// Where It Appears

Order confirmation and shipping notification emails in e-commerce applications
Subscription renewal and payment receipt emails
Microservice notification services that cache user profile data for performance
Any notification pipeline that resolves contact details from a cache without invalidating on profile updates

// REPRODUCE & TEST

// How to Reproduce

01Log in as user-b@example.com and update the email address to a new value — this populates the notification service cache with user-b's original address
02Log out of user-b's session
03Log in as user-a@example.com and place an order; note the order ID (e.g. 501)
04Wait for the order confirmation email to arrive
05Check the inbox of user-a@example.com — the email should arrive here
06Also check the inbox of user-b's ORIGINAL email address — if the confirmation email arrives there instead, the wrong-user bug is confirmed

// Test Data Needed

Two test user accounts: user-a@example.com (places the order) and user-b@example.com (the previously-cached account)
Test email inboxes for both accounts (Mailtrap, Mailhog, or real email addresses)
Ability to place a test order as user-a

// Manual Testing Ideas

Change user-b's email address, then place an order as user-a; check both inboxes to see which one receives the confirmation
Restart the notification service between the email change and the order placement to test whether the service-startup snapshot scenario also triggers the bug
Test with multiple users changing their email in rapid succession before a batch notification job runs — check whether any notification lands in the wrong inbox
Check the notification service's cache invalidation logic: does the user-profile-updated event trigger a cache eviction for that user ID?
Verify by querying GET /api/users/user-a-id that user-a's stored email is correct — this confirms the source-of-truth is right and the bug is in the notification layer's cache

// API Testing Ideas

As user-a, send GET /api/users/me and confirm the email field is user-a@example.com
As user-a, place a test order: POST /api/orders with a valid order body; capture the returned order ID (e.g. 501)
Trigger an order confirmation notification: POST /api/notifications/order-confirmation with body { "orderId": 501 } (or wait for the order event to trigger the notification automatically)
After 30 seconds, query the Mailtrap/Mailhog API for emails received at user-a@example.com with a subject matching 'Order Confirmation'
Assert exactly one email arrived at user-a@example.com and zero emails arrived at user-b@example.com or any other address

// Automation Idea

Using two Mailtrap inboxes, run a test that: (1) updates user-b's email address, (2) places an order as user-a, (3) waits 30 seconds, (4) queries both inboxes for order confirmation emails. Assert user-a's inbox has exactly one confirmation and user-b's inbox has zero. Repeat after a notification-service cache eviction to confirm the fix works for a freshly resolved address.

// Expected Result

Order confirmation email for order 501 is delivered only to user-a@example.com — the owner of the order — regardless of which other users' addresses are cached in the notification service.

// Actual Result (Example)

After user-a places order 501, the order confirmation email is delivered to user-b@example.com (the previously cached address) rather than user-a@example.com. The email body correctly references order 501 and user-a's items, but it is sent to the wrong recipient.

// REPORT IT

Example Bug Report

Title: Order 501 confirmation email delivered to user-b@example.com instead of order owner user-a@example.com
Severity: High
Environment: Staging environment Mailtrap inboxes for user-a@example.com and user-b@example.com Two standard user accounts Notification service with in-memory address cache
Steps to Reproduce: 01Log in as user-b@example.com and update the account email to user-b-new@example.com (this populates the cache with user-b's original address)
02Log out of user-b's session
03Log in as user-a@example.com and place an order; note the order ID (501)
04Wait 60 seconds for the confirmation email to be delivered
05Check the Mailtrap inbox for user-a@example.com
06Also check the Mailtrap inbox for user-b@example.com (the originally-cached address)
Expected Result: The order confirmation email for order 501 arrives in user-a@example.com's inbox. No email is delivered to user-b@example.com.
Actual Result: The order confirmation email for order 501 is delivered to user-b@example.com. The inbox of user-a@example.com receives no confirmation. The email body contains user-a's order details, confirming the right notification was triggered but sent to the wrong address.
Impact: User-a does not receive their order confirmation. User-b receives private order information belonging to user-a, a privacy and data protection violation. At scale, if many users change their email addresses, a significant portion of transactional emails can be misdirected.