fix(affiliate): require an active affiliate to attribute a swap - #56
Conversation
`isActive` was settable through the registry API but no query read it, so deactivating an affiliate did nothing to stop it being attributed on new swaps. `resolvePartner` now requires it on both the partner-code and the partner-address path. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Warning Review limit reachedNext included review available in 52 minutes. View limit detailsLimit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthrough
ChangesPartner resolution
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: 🟡 Moderate · up to The change blocks inactive affiliate codes, but an address-only request can still persist the supplied partner address without a unique active-affiliate match, so deactivated affiliates may remain attributable through that path. This should be corrected or explicitly accepted before merging. Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Full details: Docstring CoverageExplanation No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 2 files. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Replaces the jest.fn() prisma mocks with typed stubs and a call recorder, clearing 13 no-unsafe-* lint errors. Also fixes a test that did not test what it claimed: "does not let a deactivated partner slip back in via its own address" passed with the address-path isActive filter removed, because it was really re-asserting the partner-code guard. It now asserts the fall-through it actually covers, and a new assertion pins the findUnique lookup to the supplied partner code, which nothing checked before. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…vate resolver Moves the tests up to createSwap so they assert what is actually written to the swaps table, and renames the file to match. The previous tests drove the private resolvePartner and so could only observe its return value. That left the regressions that matter uncovered: passing the caller's partnerCode or partnerAddress straight through to the row instead of the registry- resolved value. Both now fail a test. Verified by mutation — each of the four tests catches exactly one regression: drop the partner-code isActive guard -> deactivated partner is attributed drop the address-path isActive filter -> filter no longer requested persist caller-supplied partnerAddress -> address not resolved from registry persist caller-supplied partnerCode -> resolution bypassed entirely Dropped two tests that earned nothing: one asserted a fall-through with no behavioural consequence, the other duplicated the partner-code guard while its name promised address-path coverage. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
1 participant
Description
isActiveon the affiliate registry was settable through the API but no query ever read it, so deactivating an affiliate had no effect — it could still be attributed on new swaps indefinitely.resolvePartnernow requires an active affiliate on both resolution paths: the partner-code lookup checks the flag, and the partner-address lookup filters on it, so a deactivated affiliate can't be reattached via its own wallet or receive address either. An attempted attribution to a deactivated code logs a warning and falls through to unattributed.Testing
yarn testinapps/swap-service— 67/67 pass, including 5 newresolvePartnercases covering the active path, the deactivated code path, address fallback, and the no-partner default.Summary by CodeRabbit
Bug Fixes
Tests