refactor(organizations): emit organization.created and move signup grant to a billing subscriber#3957
Conversation
…ant to a billing subscriber Organizations previously imported BillingSignupGrantService directly from two call sites (organizations.crud.service.js::create, added #3949, and the older organizations.service.js::createOrganizationForUser, since #3663), making billing<->organizations coupling bidirectional and breaking the module- removability guarantee. Adds a creation-side seam mirroring the existing organization.provisioned event: both call sites now emit `organization.created` ({ orgId, planId }) on the organizations events singleton instead of calling billing directly. billing.init.js subscribes next to the existing organization.provisioned listener and credits the one-shot signupGrant, following the same fire-and-forget / self-guarded pattern (listener errors swallowed+logged, grant failure never rolls back org creation, refId idempotence unchanged). Adapts organizations.integration.tests.js and billing.referral.integration.tests.js to the new async-listener timing (poll for the ledger entry / wait for it to settle before snapshotting balances), mirroring the existing waitForLedgerEntry pattern already used for the referral grant listener. Closes #3952 Claude-Session: https://claude.ai/code/session_01WfNC8bt1TgL4AsiYgCEGup
|
Warning Review limit reached
Next review available in: 50 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (1)
WalkthroughOrganization creation now emits a guarded ChangesSignup grant event integration
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant OrganizationsService
participant organizationEvents
participant billingInit
participant BillingSignupGrantService
OrganizationsService->>organizationEvents: emit organization.created
organizationEvents->>billingInit: invoke registered listener
billingInit->>BillingSignupGrantService: grantOnSignup with orgId and planId
Possibly related issues
Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 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 |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #3957 +/- ##
==========================================
+ Coverage 92.70% 92.71% +0.01%
==========================================
Files 169 169
Lines 5563 5573 +10
Branches 1791 1792 +1
==========================================
+ Hits 5157 5167 +10
Misses 326 326
Partials 80 80
Flags with carried forward coverage won't be shown. Click here to find out more. Continue to review full report in Codecov by Harness.
🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@modules/billing/tests/billing.referral.integration.tests.js`:
- Around line 106-111: Capture the return value of waitForLedgerEntry for
adminOrgId and assert it is not null before continuing; apply the same
capture-and-assert change to the waitForLedgerEntry call for refereeOrgId in
modules/billing/tests/billing.referral.integration.tests.js lines 106-111 and
174-177. This ensures both polled ledger entries are found and failures report
immediately.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 0c33e206-e424-4922-9eb4-2a68cdaef65c
📒 Files selected for processing (10)
modules/billing/billing.init.jsmodules/billing/tests/billing.init.unit.tests.jsmodules/billing/tests/billing.referral.integration.tests.jsmodules/organizations/lib/events.jsmodules/organizations/services/organizations.crud.service.jsmodules/organizations/services/organizations.service.jsmodules/organizations/tests/organizations.crud.grant.unit.tests.jsmodules/organizations/tests/organizations.emailVerification.policy.unit.tests.jsmodules/organizations/tests/organizations.integration.tests.jsmodules/organizations/tests/organizations.service.signup.unit.tests.js
💤 Files with no reviewable changes (1)
- modules/organizations/tests/organizations.emailVerification.policy.unit.tests.js
…on test CodeRabbit nit on PR #3957 — the admin and referee signup-grant polls in billing.referral.integration.tests.js returned the ledger entry but never asserted it, so a poll timeout would surface as a cryptic downstream balance mismatch instead of a clear not-null failure at the source.
Summary
organizations.crud.service.js::createandorganizations.service.js::createOrganizationForUserno longer importBillingSignupGrantServicedirectly. Both now emit anorganization.createdevent through the module's existing event seam (modules/organizations/lib/events.js, which already carriesorganization.provisioned). Billing subscribes toorganization.createdinbilling.init.jsand issues the signup grant from there.organizations.crud.service.jspath added in fix(billing): credit signupGrant on the generic org-creation path #3949, and the olderorganizations.service.jspath since feat(billing): credit signupGrant on org creation post-signup #3663), making the coupling bidirectional and breaking the module-removability guarantee — organizations should stay decoupled and optional from billing's perspective. The module already has a sanctioned seam for exactly this kind of fan-out (organization.provisioned→billing.init.js); this PR adds the creation-side counterpart instead of inventing a new pattern.Scope
organizations(emit event only, no behavior change to org creation),billing(new subscriber inbilling.init.jsthat owns the grant call)yes— billing now listens on the organizations event bus instead of organizations importing billing directly; the dependency direction flips to match the existingorganization.provisionedprecedent. No public API/route changes.low— grant issuance stays idempotent viarefIdand a grant failure still never blocks or rolls back org creation (same guarantee as before, just moved behind the event boundary).Validation
npm run lintnpm testGuardrails check
.env*,secrets/**, keys, tokens)Notes for reviewers
waitForLedgerEntrypoll pattern already used elsewhere in the billing tests, since the grant now fires from an event handler instead of an inline await.https://claude.ai/code/session_01WfNC8bt1TgL4AsiYgCEGup
Summary by CodeRabbit
New Features
Documentation
Bug Fixes