fix(billing): stop the repair reporting already-reconciled rows - #39
Merged
Conversation
After marking the live subscription non-recurring, re-running the repair still reported one row outstanding — "auto_renews false -> false" — and would have done so on every run for ever. The selection is provider_sub_id NOT LIKE 'SUB_%', which stays true permanently for a bank-transfer payment: there is no subscription at Paystack, so a SUB_ code will never appear. Harmless in effect, since re-marking is idempotent, but it destroys the "nothing to do" signal that says the system is clean. A row already marked non-recurring has been reconciled, so it is now excluded. Also makes two zero-value hazards explicit. models.Subscription.AutoRenews defaults to false, meaning "does not renew" — the test fixture was seeding rows that way without intending to, which is what surfaced this. Both production write paths set it explicitly, so nothing was affected, but the synthetic free subscription returned for users without a row now sets it too, rather than reporting a free plan as something that will not renew.
Contributor
Deploying hookdrop-frontend with
|
| Latest commit: |
5060eda
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://2636964f.hookdrop-frontend.pages.dev |
| Branch Preview URL: | https://fix-repair-skips-reconciled.hookdrop-frontend.pages.dev |
Contributor
Deploying hookdrop with
|
| Latest commit: |
5060eda
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://7cc13f28.hookdrop.pages.dev |
| Branch Preview URL: | https://fix-repair-skips-reconciled.hookdrop.pages.dev |
EOEboh
added a commit
that referenced
this pull request
Aug 3, 2026
#39) After marking the live subscription non-recurring, re-running the repair still reported one row outstanding — "auto_renews false -> false" — and would have done so on every run for ever. The selection is provider_sub_id NOT LIKE 'SUB_%', which stays true permanently for a bank-transfer payment: there is no subscription at Paystack, so a SUB_ code will never appear. Harmless in effect, since re-marking is idempotent, but it destroys the "nothing to do" signal that says the system is clean. A row already marked non-recurring has been reconciled, so it is now excluded. Also makes two zero-value hazards explicit. models.Subscription.AutoRenews defaults to false, meaning "does not renew" — the test fixture was seeding rows that way without intending to, which is what surfaced this. Both production write paths set it explicitly, so nothing was affected, but the synthetic free subscription returned for users without a row now sets it too, rather than reporting a free plan as something that will not renew.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Found while running the repair on production after #38.
The live subscription was correctly marked
auto_renews=0, but re-running the repair still reported one row outstanding:The selection is
provider_sub_id NOT LIKE 'SUB_%', which is permanently true for a bank-transfer payment — there is no subscription at Paystack, so aSUB_code will never appear. Re-marking is idempotent so nothing breaks, but it means the command can never report "nothing to do", which is the signal that tells you the system is clean.Rows already marked non-recurring are now excluded.
Also makes a zero-value hazard explicit:
AutoRenewsdefaults tofalse, i.e. "does not renew". The test fixture was seeding rows that way unintentionally, which is how this surfaced. Both production write paths set it explicitly so nothing was affected, but the synthetic free subscription now sets it too rather than describing a free plan as non-renewing.Your subscription is already correct — this is cleanup.