The Self-Cancelling Subscription

· coding · Source ↗

TLDR

  • A streaming perk linked to a credit card kept self-cancelling every 5 minutes due to a sync-vs-async race condition between bank and streaming provider systems.

Key Takeaways

  • Account linking is synchronous for UX reasons; unlinking is async for resilience, creating a window where out-of-order event delivery cancels a freshly re-linked subscription.
  • The fix: unlink, wait overnight for the async teardown workflow to fully complete, then re-link. No cancellation returned.
  • Root cause was likely an expired card triggering an erroneous payment flow that unlinked the credit card perk, compounding the async ordering issue.
  • Both support teams saw only orderly activation-then-cancellation with no errors, making cross-org black-box debugging the only path forward.
  • The fix suggested for the architecture: replace a boolean “linked” flag with a versioned or timestamped state so stale async events cannot override newer ones.

Hacker News Comment Review

  • Commenters converged on the same architectural fix independently: the boolean linked/unlinked flag is the core flaw; a version counter or timestamp would make stale async cancellation events idempotent.
  • The support ping-pong is explained by each side being technically correct in isolation; the bug only exists in the interaction between the two systems, invisible to either party’s logs.
  • Several commenters skipped the debugging framing entirely, treating the incident as an argument for piracy, service-switching, or usage-based billing that auto-cancels on non-use.

Notable Comments

  • @xp84: The boolean flag needs replacement with versioned state; local test latency of ~5ms versus production latency of up to 5 minutes is exactly why this passed QA.
  • @eduction: The discrepancy between the two support teams’ logs was already detectable during the support calls and pointed directly to the async ordering failure.

Original | Discuss on HN