Skip Fraud detection for inactive program enrollments #3237
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
WalkthroughRefactors commission creation so callers consume a unified Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes
Possibly related PRs
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: defaults Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
🧰 Additional context used🧠 Learnings (4)📓 Common learnings📚 Learning: 2025-12-08T09:44:28.429ZApplied to files:
📚 Learning: 2025-10-02T22:46:22.739ZApplied to files:
📚 Learning: 2025-06-06T07:59:03.120ZApplied to files:
🧬 Code graph analysis (1)apps/web/app/(ee)/api/stripe/integration/webhook/checkout-session-completed.ts (5)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
🔇 Additional comments (3)
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 |
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
apps/web/app/(ee)/api/stripe/integration/webhook/checkout-session-completed.ts (1)
628-668: Note: attributeViaPromoCode uses a different pattern.The
attributeViaPromoCodehelper (lines 628-668) still uses the older pattern of extractingwebhookPartnervia.then()and doesn't invokedetectAndRecordFraudEventfor lead events. This is acceptable since:
- The lead creation here is part of a promo code attribution flow
- The subsequent sale in the main flow will trigger fraud detection with the updated pattern
If fraud detection for promo-code-attributed leads becomes a requirement, this section would need updating.
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (9)
apps/web/app/(ee)/api/stripe/integration/webhook/checkout-session-completed.ts(4 hunks)apps/web/app/(ee)/api/stripe/integration/webhook/invoice-paid.ts(5 hunks)apps/web/app/(ee)/api/stripe/integration/webhook/utils/create-new-customer.ts(3 hunks)apps/web/lib/api/conversions/track-lead.ts(5 hunks)apps/web/lib/api/conversions/track-sale.ts(7 hunks)apps/web/lib/api/fraud/detect-record-fraud-event.ts(2 hunks)apps/web/lib/integrations/shopify/create-sale.ts(5 hunks)apps/web/lib/partners/create-partner-commission.ts(8 hunks)apps/web/lib/zod/schemas/schemas.ts(2 hunks)
🧰 Additional context used
🧠 Learnings (11)
📓 Common learnings
Learnt from: devkiran
Repo: dubinc/dub PR: 3175
File: apps/web/lib/actions/partners/bulk-reject-partner-applications.ts:14-21
Timestamp: 2025-12-03T09:19:48.164Z
Learning: In apps/web/lib/actions/partners/bulk-reject-partner-applications.ts, the bulkRejectPartnerApplicationsAction does not need explicit plan capability checks for fraud operations (when reportFraud is true) because the authorization is handled automatically by the underlying fraud operation functions (resolveFraudGroups, createFraudEvents) or through other automated mechanisms in the system.
Learnt from: devkiran
Repo: dubinc/dub PR: 3200
File: apps/web/lib/api/fraud/detect-duplicate-payout-method-fraud.ts:55-73
Timestamp: 2025-12-08T09:44:28.429Z
Learning: In apps/web/lib/api/fraud/detect-duplicate-payout-method-fraud.ts, the fraud event creation logic intentionally generates self-referential fraud events (where partnerId equals duplicatePartnerId) for partners with duplicate payout methods. This is by design to create raw events for all partners involved in a duplicate payout method scenario, regardless of whether they reference themselves.
📚 Learning: 2025-12-08T09:44:28.429Z
Learnt from: devkiran
Repo: dubinc/dub PR: 3200
File: apps/web/lib/api/fraud/detect-duplicate-payout-method-fraud.ts:55-73
Timestamp: 2025-12-08T09:44:28.429Z
Learning: In apps/web/lib/api/fraud/detect-duplicate-payout-method-fraud.ts, the fraud event creation logic intentionally generates self-referential fraud events (where partnerId equals duplicatePartnerId) for partners with duplicate payout methods. This is by design to create raw events for all partners involved in a duplicate payout method scenario, regardless of whether they reference themselves.
Applied to files:
apps/web/lib/zod/schemas/schemas.tsapps/web/lib/api/conversions/track-lead.tsapps/web/app/(ee)/api/stripe/integration/webhook/checkout-session-completed.tsapps/web/lib/integrations/shopify/create-sale.tsapps/web/app/(ee)/api/stripe/integration/webhook/invoice-paid.tsapps/web/lib/api/fraud/detect-record-fraud-event.tsapps/web/lib/partners/create-partner-commission.tsapps/web/app/(ee)/api/stripe/integration/webhook/utils/create-new-customer.tsapps/web/lib/api/conversions/track-sale.ts
📚 Learning: 2025-11-24T09:10:12.536Z
Learnt from: devkiran
Repo: dubinc/dub PR: 3089
File: apps/web/lib/api/fraud/fraud-rules-registry.ts:17-25
Timestamp: 2025-11-24T09:10:12.536Z
Learning: In apps/web/lib/api/fraud/fraud-rules-registry.ts, the fraud rules `partnerCrossProgramBan` and `partnerDuplicatePayoutMethod` intentionally have stub implementations that return `{ triggered: false }` because they are partner-scoped rules handled separately during partner application/onboarding flows (e.g., in detect-record-fraud-application.ts), rather than being evaluated per conversion event like other rules in the registry. The stubs exist only to satisfy the `Record<FraudRuleType, ...>` type constraint.
Applied to files:
apps/web/lib/zod/schemas/schemas.tsapps/web/lib/api/conversions/track-lead.tsapps/web/app/(ee)/api/stripe/integration/webhook/invoice-paid.tsapps/web/lib/api/fraud/detect-record-fraud-event.tsapps/web/app/(ee)/api/stripe/integration/webhook/utils/create-new-customer.tsapps/web/lib/api/conversions/track-sale.ts
📚 Learning: 2025-10-17T08:18:19.278Z
Learnt from: devkiran
Repo: dubinc/dub PR: 0
File: :0-0
Timestamp: 2025-10-17T08:18:19.278Z
Learning: In the apps/web codebase, `@/lib/zod` should only be used for places that need OpenAPI extended zod schema. All other places should import from the standard `zod` package directly using `import { z } from "zod"`.
Applied to files:
apps/web/lib/zod/schemas/schemas.ts
📚 Learning: 2025-10-02T22:46:22.739Z
Learnt from: steven-tey
Repo: dubinc/dub PR: 2924
File: apps/web/lib/api/conversions/track-lead.ts:7-7
Timestamp: 2025-10-02T22:46:22.739Z
Learning: In apps/web/lib/api/conversions/track-lead.ts, lead events are cached in Redis for 5 minutes (keys: `leadCache:${customer.id}` and `leadCache:${customer.id}:${stringifiedEventName}`) to provide immediate data availability while Tinybird ingestion happens asynchronously. This caching pattern allows for async-only recording without breaking "wait" mode semantics.
Applied to files:
apps/web/lib/api/conversions/track-lead.tsapps/web/lib/integrations/shopify/create-sale.tsapps/web/lib/api/conversions/track-sale.ts
📚 Learning: 2025-08-25T17:33:45.072Z
Learnt from: devkiran
Repo: dubinc/dub PR: 2736
File: apps/web/app/(ee)/api/stripe/integration/webhook/invoice-paid.ts:12-12
Timestamp: 2025-08-25T17:33:45.072Z
Learning: The WorkflowTrigger enum in packages/prisma/schema/workflow.prisma contains three values: leadRecorded, saleRecorded, and commissionEarned. All three are properly used throughout the codebase.
Applied to files:
apps/web/lib/integrations/shopify/create-sale.tsapps/web/app/(ee)/api/stripe/integration/webhook/invoice-paid.tsapps/web/app/(ee)/api/stripe/integration/webhook/utils/create-new-customer.ts
📚 Learning: 2025-06-06T07:59:03.120Z
Learnt from: devkiran
Repo: dubinc/dub PR: 2177
File: apps/web/lib/api/links/bulk-create-links.ts:66-84
Timestamp: 2025-06-06T07:59:03.120Z
Learning: In apps/web/lib/api/links/bulk-create-links.ts, the team accepts the risk of potential undefined results from links.find() operations when building invalidLinks arrays, because existing links are fetched from the database based on the input links, so matches are expected to always exist.
Applied to files:
apps/web/lib/integrations/shopify/create-sale.tsapps/web/app/(ee)/api/stripe/integration/webhook/invoice-paid.tsapps/web/app/(ee)/api/stripe/integration/webhook/utils/create-new-customer.tsapps/web/lib/api/conversions/track-sale.ts
📚 Learning: 2025-12-03T09:19:48.164Z
Learnt from: devkiran
Repo: dubinc/dub PR: 3175
File: apps/web/lib/actions/partners/bulk-reject-partner-applications.ts:14-21
Timestamp: 2025-12-03T09:19:48.164Z
Learning: In apps/web/lib/actions/partners/bulk-reject-partner-applications.ts, the bulkRejectPartnerApplicationsAction does not need explicit plan capability checks for fraud operations (when reportFraud is true) because the authorization is handled automatically by the underlying fraud operation functions (resolveFraudGroups, createFraudEvents) or through other automated mechanisms in the system.
Applied to files:
apps/web/lib/api/fraud/detect-record-fraud-event.ts
📚 Learning: 2025-11-24T08:55:31.332Z
Learnt from: devkiran
Repo: dubinc/dub PR: 3089
File: apps/web/app/(ee)/api/fraud-rules/route.ts:71-87
Timestamp: 2025-11-24T08:55:31.332Z
Learning: In apps/web/app/(ee)/api/fraud-rules/route.ts, fraud rules cannot be created in a disabled state. When using prisma.fraudRule.upsert, the create branch intentionally omits the disabledAt field (defaulting to null, meaning enabled), while the update branch allows toggling enabled/disabled state via the disabledAt field. This is a business logic constraint.
Applied to files:
apps/web/lib/api/fraud/detect-record-fraud-event.ts
📚 Learning: 2025-11-12T22:23:10.414Z
Learnt from: TWilson023
Repo: dubinc/dub PR: 3098
File: apps/web/lib/actions/partners/message-program.ts:49-58
Timestamp: 2025-11-12T22:23:10.414Z
Learning: In apps/web/lib/actions/partners/message-program.ts, when checking if a partner can continue messaging after messaging is disabled, the code intentionally requires `senderPartnerId: null` (program-initiated messages) to prevent partners from continuing to send junk messages. Only conversations started by the program should continue after messaging is disabled, as a spam prevention mechanism.
Applied to files:
apps/web/lib/api/fraud/detect-record-fraud-event.ts
📚 Learning: 2025-09-17T17:44:03.965Z
Learnt from: TWilson023
Repo: dubinc/dub PR: 2857
File: apps/web/lib/actions/partners/update-program.ts:96-0
Timestamp: 2025-09-17T17:44:03.965Z
Learning: In apps/web/lib/actions/partners/update-program.ts, the team prefers to keep the messagingEnabledAt update logic simple by allowing client-provided timestamps rather than implementing server-controlled timestamp logic to avoid added complexity.
Applied to files:
apps/web/lib/partners/create-partner-commission.ts
🧬 Code graph analysis (6)
apps/web/lib/api/conversions/track-lead.ts (2)
apps/web/lib/partners/create-partner-commission.ts (1)
createPartnerCommission(60-401)packages/utils/src/functions/pick.ts (1)
pick(3-8)
apps/web/app/(ee)/api/stripe/integration/webhook/checkout-session-completed.ts (4)
apps/web/app/(ee)/api/stripe/integration/webhook/utils/get-subscription-product-id.ts (1)
getSubscriptionProductId(4-29)packages/utils/src/functions/pick.ts (1)
pick(3-8)apps/web/lib/webhook/publish.ts (1)
sendWorkspaceWebhook(8-45)apps/web/lib/webhook/transform.ts (1)
transformSaleEventData(81-108)
apps/web/app/(ee)/api/stripe/integration/webhook/invoice-paid.ts (2)
apps/web/lib/partners/create-partner-commission.ts (1)
createPartnerCommission(60-401)packages/utils/src/functions/pick.ts (1)
pick(3-8)
apps/web/lib/api/fraud/detect-record-fraud-event.ts (1)
apps/web/lib/zod/schemas/partners.ts (1)
INACTIVE_ENROLLMENT_STATUSES(26-30)
apps/web/app/(ee)/api/stripe/integration/webhook/utils/create-new-customer.ts (3)
apps/web/lib/partners/create-partner-commission.ts (1)
createPartnerCommission(60-401)apps/web/lib/api/partners/sync-partner-links-stats.ts (1)
syncPartnerLinksStats(5-62)packages/utils/src/functions/pick.ts (1)
pick(3-8)
apps/web/lib/api/conversions/track-sale.ts (1)
apps/web/lib/partners/create-partner-commission.ts (1)
createPartnerCommission(60-401)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: build
🔇 Additional comments (19)
apps/web/lib/api/fraud/detect-record-fraud-event.ts (1)
22-30: LGTM! Well-placed early guard for inactive enrollments.The guard correctly skips fraud detection for inactive program enrollments (banned, deactivated, rejected) before performing expensive operations like database queries and rule evaluation. This is a sensible optimization.
apps/web/lib/zod/schemas/schemas.ts (1)
13-15: LGTM! Schema correctly captures the required enrollment status.Using
ProgramEnrollmentSchema.pick({ status: true })is appropriate - it provides exactly the field needed for the inactive enrollment check while keeping the schema minimal.apps/web/lib/integrations/shopify/create-sale.ts (2)
134-160: LGTM! Consistent pattern for commission result handling.The refactor correctly:
- Captures the full
createPartnerCommissionresult- Destructures
webhookPartnerandprogramEnrollmentinside the conditional block wherecreatedCommissionis guaranteed to be defined- Passes
programEnrollmentto fraud detection
182-193: Fraud detection now includes programEnrollment status.The
programEnrollment: pick(programEnrollment, ["status"])correctly provides the status field needed for the inactive enrollment guard indetectAndRecordFraudEvent.apps/web/lib/partners/create-partner-commission.ts (2)
109-113: Consistent return shape across all code paths.All early return paths now correctly include
programEnrollmentin the return object, ensuring callers always have access to enrollment data regardless of whether a commission was created.
381-399: Return type correctly extended for success and error paths.Both the success path (lines 381-385) and error path (lines 395-399) return
{ commission, programEnrollment, webhookPartner }, maintaining a consistent return shape that downstream callers can rely on.apps/web/app/(ee)/api/stripe/integration/webhook/invoice-paid.ts (2)
216-243: LGTM! Follows the consistent commission result handling pattern.The refactoring mirrors the pattern used in other files:
- Stores the full
createPartnerCommissionresult increatedCommission- Destructures
webhookPartnerandprogramEnrollmentwithin the conditional block- Uses optional chaining for the final webhook payload
265-274: Fraud detection correctly receives programEnrollment status.The
programEnrollment: pick(programEnrollment, ["status"])ensures the fraud detection flow can evaluate the inactive enrollment guard.apps/web/lib/api/conversions/track-lead.ts (2)
297-317: LGTM! Consistent commission handling in lead tracking.The pattern correctly captures the
createPartnerCommissionresult and destructureswebhookPartnerandprogramEnrollmentfor downstream use in fraud detection and webhook payloads.
337-347: Fraud detection correctly integrated with programEnrollment.The fraud detection call properly includes
programEnrollment: pick(programEnrollment, ["status"])to support the inactive enrollment guard.apps/web/lib/api/conversions/track-sale.ts (3)
348-362: LGTM! Direct destructuring appropriate for _trackLead.Since
_trackLeaddoesn't need to passwebhookPartnerto an external webhook payload (unlike the maintrackLeadfunction), directly destructuring{ webhookPartner, programEnrollment }is appropriate here.
548-576: Consistent pattern in _trackSale for commission handling.The
_trackSalefunction correctly stores the fullcreatePartnerCommissionresult to support both fraud detection (withprogramEnrollment) and the workspace webhook (withwebhookPartner).
597-607: Fraud detection correctly integrated.Both
_trackLead(line 386) and_trackSale(line 601) now correctly passprogramEnrollment: pick(programEnrollment, ["status"])to enable the inactive enrollment guard.apps/web/app/(ee)/api/stripe/integration/webhook/checkout-session-completed.ts (2)
434-467: LGTM! Main checkout flow correctly updated.The primary
checkoutSessionCompletedflow properly:
- Captures the
createPartnerCommissionresult- Destructures
webhookPartnerandprogramEnrollment- Passes
programEnrollmentto fraud detection
489-498: Fraud detection correctly receives programEnrollment.The
programEnrollment: pick(programEnrollment, ["status"])enables the inactive enrollment guard for checkout-originated sales.apps/web/app/(ee)/api/stripe/integration/webhook/utils/create-new-customer.ts (4)
106-108: Clean type annotation for conditional commission result.The explicit typing using
Awaited<ReturnType<typeof createPartnerCommission>>correctly captures the resolved promise type and the| undefinedunion properly handles the conditional assignment path.
111-127: Good refactor to derive partner/enrollment data from commission result.Storing the commission result and destructuring
webhookPartnerandprogramEnrollmentmakes the data flow explicit and aligns with the pattern used in other call sites per the PR's cross-file changes.
128-158: Well-structured background task execution with proper fraud detection guard.Using
Promise.allSettledensures all background operations are attempted even if one fails. ThewebhookPartner &&guard on line 147 appropriately skips fraud detection when partner data is unavailable, and passingprogramEnrollment.status(line 151) supports the PR objective of skipping fraud detection for inactive enrollments.Note that errors from these settled promises are silently dropped, which is typical for fire-and-forget patterns but may make debugging harder if issues arise.
161-175: Correct use of optional chaining for webhook partner data.The
createdCommission?.webhookPartnersafely handles cases where no commission was created (when the link has noprogramId/partnerId), ensuring the workspace webhook still fires for all lead events.
There was a problem hiding this comment.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
apps/web/app/(ee)/api/stripe/integration/webhook/checkout-session-completed.ts (1)
484-493: Guard against nullprogramEnrollmentbefore callingpick.The fraud detection is guarded by
webhookPartner &&but line 488 usespick(programEnrollment, ["status"])without verifying thatprogramEnrollmentexists. According to the context fromcreate-partner-commission.ts,programEnrollmentcan be null or undefined in error cases, which would causepickto throw since it expects an object.Apply this diff to add a null check:
- webhookPartner && + webhookPartner && programEnrollment && detectAndRecordFraudEvent({ program: { id: link.programId }, partner: pick(webhookPartner, ["id", "email", "name"]), programEnrollment: pick(programEnrollment, ["status"]), customer: pick(customer, ["id", "email", "name"]), link: pick(link, ["id"]), click: pick(saleData, ["url", "referer"]), event: { id: saleData.event_id }, }),Alternatively, if fraud detection should be called even without enrollment data, adjust the payload:
webhookPartner && detectAndRecordFraudEvent({ program: { id: link.programId }, partner: pick(webhookPartner, ["id", "email", "name"]), - programEnrollment: pick(programEnrollment, ["status"]), + programEnrollment: programEnrollment ? pick(programEnrollment, ["status"]) : undefined, customer: pick(customer, ["id", "email", "name"]), link: pick(link, ["id"]), click: pick(saleData, ["url", "referer"]), event: { id: saleData.event_id }, }),
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
apps/web/app/(ee)/api/stripe/integration/webhook/checkout-session-completed.ts(8 hunks)
🧰 Additional context used
🧠 Learnings (4)
📓 Common learnings
Learnt from: devkiran
Repo: dubinc/dub PR: 3200
File: apps/web/lib/api/fraud/detect-duplicate-payout-method-fraud.ts:55-73
Timestamp: 2025-12-08T09:44:28.429Z
Learning: In apps/web/lib/api/fraud/detect-duplicate-payout-method-fraud.ts, the fraud event creation logic intentionally generates self-referential fraud events (where partnerId equals duplicatePartnerId) for partners with duplicate payout methods. This is by design to create raw events for all partners involved in a duplicate payout method scenario, regardless of whether they reference themselves.
Learnt from: devkiran
Repo: dubinc/dub PR: 3089
File: apps/web/lib/api/fraud/fraud-rules-registry.ts:17-25
Timestamp: 2025-11-24T09:10:12.536Z
Learning: In apps/web/lib/api/fraud/fraud-rules-registry.ts, the fraud rules `partnerCrossProgramBan` and `partnerDuplicatePayoutMethod` intentionally have stub implementations that return `{ triggered: false }` because they are partner-scoped rules handled separately during partner application/onboarding flows (e.g., in detect-record-fraud-application.ts), rather than being evaluated per conversion event like other rules in the registry. The stubs exist only to satisfy the `Record<FraudRuleType, ...>` type constraint.
📚 Learning: 2025-12-08T09:44:28.429Z
Learnt from: devkiran
Repo: dubinc/dub PR: 3200
File: apps/web/lib/api/fraud/detect-duplicate-payout-method-fraud.ts:55-73
Timestamp: 2025-12-08T09:44:28.429Z
Learning: In apps/web/lib/api/fraud/detect-duplicate-payout-method-fraud.ts, the fraud event creation logic intentionally generates self-referential fraud events (where partnerId equals duplicatePartnerId) for partners with duplicate payout methods. This is by design to create raw events for all partners involved in a duplicate payout method scenario, regardless of whether they reference themselves.
Applied to files:
apps/web/app/(ee)/api/stripe/integration/webhook/checkout-session-completed.ts
📚 Learning: 2025-10-02T22:46:22.739Z
Learnt from: steven-tey
Repo: dubinc/dub PR: 2924
File: apps/web/lib/api/conversions/track-lead.ts:7-7
Timestamp: 2025-10-02T22:46:22.739Z
Learning: In apps/web/lib/api/conversions/track-lead.ts, lead events are cached in Redis for 5 minutes (keys: `leadCache:${customer.id}` and `leadCache:${customer.id}:${stringifiedEventName}`) to provide immediate data availability while Tinybird ingestion happens asynchronously. This caching pattern allows for async-only recording without breaking "wait" mode semantics.
Applied to files:
apps/web/app/(ee)/api/stripe/integration/webhook/checkout-session-completed.ts
📚 Learning: 2025-06-06T07:59:03.120Z
Learnt from: devkiran
Repo: dubinc/dub PR: 2177
File: apps/web/lib/api/links/bulk-create-links.ts:66-84
Timestamp: 2025-06-06T07:59:03.120Z
Learning: In apps/web/lib/api/links/bulk-create-links.ts, the team accepts the risk of potential undefined results from links.find() operations when building invalidLinks arrays, because existing links are fetched from the database based on the input links, so matches are expected to always exist.
Applied to files:
apps/web/app/(ee)/api/stripe/integration/webhook/checkout-session-completed.ts
🧬 Code graph analysis (1)
apps/web/app/(ee)/api/stripe/integration/webhook/checkout-session-completed.ts (5)
apps/web/lib/partners/create-partner-commission.ts (1)
createPartnerCommission(60-401)apps/web/app/(ee)/api/stripe/integration/webhook/utils/get-subscription-product-id.ts (1)
getSubscriptionProductId(4-29)packages/utils/src/functions/pick.ts (1)
pick(3-8)apps/web/lib/webhook/publish.ts (1)
sendWorkspaceWebhook(8-45)apps/web/lib/webhook/transform.ts (1)
transformSaleEventData(81-108)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: build
🔇 Additional comments (3)
apps/web/app/(ee)/api/stripe/integration/webhook/checkout-session-completed.ts (3)
429-462: LGTM! Commission creation flow properly structured.The declaration and assignment of
createdCommissionis correct. The function always returns an object, so the destructuring at line 462 is safe.
498-512: LGTM! Workspace webhook properly uses optional chaining.The workspace webhook correctly uses
createdCommission?.webhookPartnerwith optional chaining to safely access the partner data.
627-679: LGTM! Lead commission flow properly structured.The
createdCommissionhandling in theattributeViaPromoCodefunction follows the same pattern as the main flow. The optional chaining at line 675 correctly guards against undefined values.Note: Fraud detection is not invoked for lead events in this flow, only for sale events in the main flow. This appears intentional based on the code structure.
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.