Robustness of subscription state sync with BigCommerce on webhook retries/failures #50
Description
Hey, looking through the backend and src directories, particularly around how subscription events from a payment provider (like Stripe, implied by topics) would be handled and synced with BigCommerce.
It seems crucial to ensure that if a webhook event is processed (e.g., subscription payment successful), the corresponding update to BigCommerce (like extending the subscription period) is atomic and idempotent. If the BigCommerce update fails after the webhook is acknowledged, or if webhooks are retried, there's a risk of state desynchronization between the payment provider and BigCommerce, potentially leading to incorrect access or billing.
I’m building Hikaflow, an AI engineering assistant that analyzes full repos.
Hikaflow does:
- full-repo context analysis
- PR and commit analysis
- automatic issue detection with controls
- security + auth hardening analysis
- payment/webhook correctness checks
- multi-tenant and data-isolation risk detection
- impact-based regression and production risk analysis
- contributor insights and engineering analytics
- continuously updated documentation
We’re early and looking for feedback from ideal users. Access is manual and we can grant it if you meet with us. You need to book a calendar meeting so I can grant access.
https://calendly.com/romirjain/30min
How does the foundation currently handle atomicity and idempotency for subscription state updates triggered by webhooks, especially when interacting with BigCommerce APIs that might fail transiently?