Skip to Content
LearnCode Review5 WhysPayment Method

Payment Method

This learning is based on a real production incident that affected customers.

Let’s examine how to ensure large-refactor PRs include edge-case and regression testing, using a real-world example where deleting a modal route during Stripe clean-up left some developers unable to understand why they could not enter Mainnet.

The Scenario

A critical UI regression occurred when a Stripe billing system update required developers to re-enter payment details.

  1. Stripe billing was launched on October 31, 2024
  2. All developers were required to re-enter their card details
  3. A Payment-Method-Warning modal was designed to guide developers without updated cards
  4. On December 11, a code refactor removed the PaymentWarningModal component
  5. The route constant was replaced with a hard-coded string
  6. The hard-coded string was later deleted
  7. The modal rendered as empty but still blocked the Mainnet toggle
  8. Six developers encountered the blank dialog
  9. The issue persisted from December 11, 17:50 UTC to December 20, 02:11 UTC
  10. The problem went undetected for approximately 8 days
  11. A two-line hot-fix restored the component
  12. The fix was deployed at 04:39 UTC, 2 hours and 28 minutes after detection
index.tsx
-  router.push(modalRoutes.settings.admin.payments.check.warning) // Before refactor (July 2023)
+  router.push('/settings/admin/payments/warning') // Hot-fix restored the comment

PR Comment

Choose the comment that you think is the most constructive and helpful.

Click here to learn more

Key Lessons

1. Understanding Product Impact

  • UI regressions can silently block critical flows (Mainnet access)
  • Eight-day detection gap shows need for UX-level monitors
  • Even “internal-only” modals affect external devs during onboarding

2. Testing Strategy

  • Unit tests must cover negative paths (missing payment)
  • PRs deleting components require E2E tests or manual checklists
  • Edge-case personas (pre-Stripe devs) need explicit scenarios

3. Code/Design Review Best Practices

  • Reject hard-coded routes that bypass type safety
  • Require “Test Plan” in large cleanup PRs
  • Reviewers should ask for rollback/mitigation paths

Tips for Reviewers

1. Ask Product-Focused Questions

  • What happens if a user hits this modal today?
  • How many people are in that state?
  • Is there telemetry on modal open vs. modal render success?

2. Verify Testing Strategy

  • Does CI run an E2E that toggles Mainnet without billing?
  • Are we logging and alerting on modal render errors?
  • Do unit tests assert route constants exist?

3. Document Dependencies

  • Stripe migration flag removal timeline
  • List of modal routes and owning components
  • JIRA action items (DEV-4546, DEV-3760, DEV-4555) to raise coverage & audit hard-coded routes

Common Pitfalls to Avoid

1. Trusting “Green” Tests Only

  • ❌ “CI passed, merge.”
  • ✅ “CI passed, and we manually verified edge-case UX.”
  • ❌ Remove unused component, assume safe.
  • ✅ Search for hard-coded references, run global E2E.

3. Missing Observability for UI Failures

  • ❌ No alert because error is client-side.
  • ✅ Track modal render success, alert if < 99 %.

Remember: robust reviews weigh technical correctness, regression coverage, and product impact. Edge-case testing and observability turn “silent” UI failures into quickly mitigated non-events!

Last updated on
LaunchDarklyProduct Impact