-
Notifications
You must be signed in to change notification settings - Fork 1.5k
[PM-28423] Add latest_invoice expansion / logging to SubscriptionCancellationJob
#6603
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[PM-28423] Add latest_invoice expansion / logging to SubscriptionCancellationJob
#6603
Conversation
latest_invoice expansion / logging to SubscriptionCancellationJoblatest_invoice expansion / logging to SubscriptionCancellationJob
|
Claude finished @amorask-bitwarden's task —— View job Code Review CompleteI've reviewed the changes in this PR that fix the 🎯 SummaryThe PR successfully fixes the root cause: the job was checking ✅ What's Good
🔍 Observations & Suggestions📝 Type Consistency (Minor)The production code uses Analysis: Looking at the codebase, I see both patterns are used:
The production code correctly uses the Stripe SDK enum for type-safe comparison, while tests use string constants for mock setup. This is actually acceptable - the Stripe SDK will convert the enum to string when making API calls, and tests mock string values. However, for maximum consistency, consider using the SDK enum in tests too when setting up mocks. Recommendation: This is acceptable as-is, but for future consistency you could use 🎨 Pattern Matching SafetyThe pattern at lines 35-39 uses nested property patterns: if (subscription is not
{
Status: SubscriptionStatus.Unpaid,
LatestInvoice: { BillingReason: BillingReasons.SubscriptionCreate or BillingReasons.SubscriptionCycle }
})This pattern implicitly checks that 🔐 Security Considerations
📊 Test Coverage AnalysisThe test suite is comprehensive and covers:
Test Quality: Excellent use of NSubstitute for mocking, clear AAA pattern, descriptive test names following conventions. 🚀 Impact AssessmentCriticality: High - This fixes a production bug where subscriptions that should be automatically cancelled were not being processed. Risk: Low - The change is minimal, well-tested, and defensive (multiple validation checks before taking action). Performance: Negligible - Adds one expansion parameter to an existing API call. ✅ Final VerdictApprove - This PR successfully fixes the bug, adds appropriate logging and test coverage, and follows Bitwarden coding standards. The previous Claude review comments have been addressed by extracting constants. The code is production-ready. Checklist:
Note: The Checkmarx findings for CSRF in |
|
New Issues (2)Checkmarx found the following issues in this Pull Request
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #6603 +/- ##
==========================================
+ Coverage 53.40% 53.45% +0.05%
==========================================
Files 1917 1917
Lines 85466 85478 +12
Branches 7667 7667
==========================================
+ Hits 45643 45694 +51
+ Misses 38056 38017 -39
Partials 1767 1767 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
sbrown-livefront
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
✅
…on-job # Conflicts: # src/Billing/Services/Implementations/UpcomingInvoiceHandler.cs


🎟️ Tracking
https://bitwarden.atlassian.net/browse/PM-28423
📔 Objective
The
SubscriptionCancellationJobwas never running because it was checking for abilling_reasonon the incoming subscription'slatest_invoicewhile never expandinglatest_invoicein the request to retrieve the subscription.This PR resolves that as well as adds logging and unit tests.
📸 Screenshots
⏰ Reminders before review
🦮 Reviewer guidelines
:+1:) or similar for great changes:memo:) or ℹ️ (:information_source:) for notes or general info:question:) for questions:thinking:) or 💭 (:thought_balloon:) for more open inquiry that's not quite a confirmed issue and could potentially benefit from discussion:art:) for suggestions / improvements:x:) or:warning:) for more significant problems or concerns needing attention:seedling:) or ♻️ (:recycle:) for future improvements or indications of technical debt:pick:) for minor or nitpick changes