Add API endpoint for partner deactivation

[devkiran]

Summary by CodeRabbit

• New Features

  • Add partner deactivation endpoint (accepts partnerId or tenantId); deactivated partners show updated enrollment status and expired links.
  • Add API schema and OpenAPI metadata for the new endpoint.

• Updates

  • Frontend now calls the single-partner deactivate API (partnerId payload).
  • Centralized deactivation processing to ensure consistent status updates and downstream notifications.

• Tests

  • Add end-to-end tests for deactivation via partnerId and tenantId; add test utility to fetch partners and verify statuses.

[devkiran]

@coderabbitai full review

[coderabbitai]

✅ Actions performed

Full review triggered.

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In `@apps/web/lib/api/partners/deactivate-partner.ts`:
- Around line 101-116: The qstash.publishJSON call in deactivatePartner can fail
silently and leave a partner deactivated without any cleanup job queued; wrap
the qstash.publishJSON invocation in a try-catch inside deactivatePartner and on
error log the failure and persist a retry entry (outbox) or set a DB flag to
trigger a background retry, so the /api/cron/partners/deactivate job can be
retried later; specifically update the block that calls qstash.publishJSON (and
its surrounding success/error branches) to catch exceptions, record the failed
job (e.g., insert a retry record referencing programId and partner.id) and
ensure the scheduled job is retriable from that persisted state (mirror the
try-catch pattern used in schedule-campaigns.ts).

🧹 Nitpick comments (1)

apps/web/lib/zod/schemas/partners.ts (1)

824-825: Adding a refinement here would duplicate runtime validation without improving OpenAPI docs.

The route already validates this requirement via throwIfNoPartnerIdOrTenantId() on line 19. Additionally, the schema documents the constraint in the tenantId field description. A refinement alone won't enhance the OpenAPI schema—zod-openapi cannot auto-translate refine() into OpenAPI constraints and requires manual .meta({ override: ... }) configuration to express the constraint in the generated schema. If strict schema-level validation is desired, add both the refinement and a corresponding .meta() override; otherwise, the current setup is sufficient.

[devkiran]

@coderabbitai full review

[coderabbitai]

✅ Actions performed

Full review triggered.

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In `@apps/web/app/`(ee)/api/partners/deactivate/route.ts:
- Around line 26-47: The current handler resolves partnerId from tenantId only
when partnerId is missing, which allows a mismatch when both tenantId and
partnerId are provided; update the logic around tenantId/partnerId in the route
handler so that if tenantId is present you always load the programEnrollment via
prisma.programEnrollment.findUnique({ where: { tenantId_programId: { tenantId,
programId } } }) and then (1) if no enrollment throw a DubApiError not_found,
and (2) if partnerId was provided and enrollment.partnerId !== partnerId throw a
DubApiError (bad_request or conflict) indicating the tenantId/partnerId
mismatch; otherwise set partnerId = enrollment.partnerId and continue. Ensure
references to tenantId, partnerId, prisma.programEnrollment, and DubApiError are
used so the change is made in the correct place.

🧹 Nitpick comments (1)

apps/web/tests/partners/deactivate-partner.test.ts (1)

14-14: Consider adding negative test cases.

The current tests cover the happy path well. Consider adding tests for edge cases such as:

• Attempting to deactivate an already deactivated partner
• Attempting to deactivate a non-existent partner
• Attempting to deactivate a banned partner (should fail per the API logic)

[steven-tey]

@coderabbitai full review, any breaking changes?

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Search for usages of bulkDeactivatePartners to check if it's used elsewhere
echo "=== Searching for bulkDeactivatePartners usage ==="
rg -n 'bulkDeactivatePartners' --type ts -C 3

echo -e "\n=== Searching for existing deactivate API endpoints ==="
rg -n 'api/partners.*deactivate' --type ts -C 2

echo -e "\n=== Check if bulkDeactivatePartners is still exported ==="
cat apps/web/lib/api/partners/bulk-deactivate-partners.ts | head -50

Length of output: 12544

---

@steven-tey: I've analyzed the PR for breaking changes - no breaking changes detected. Here's my full review:

✅ No Breaking Changes

All changes are backward compatible:

The bulkDeactivatePartners function maintains its original signature and is still used in multiple places:

• UI modal (bulk-deactivate-partners-modal.tsx)
• Server action (bulk-deactivate-partners.ts)
• Cron job (api/cron/programs/deactivate/route.ts)

Summary of Changes

Additions (non-breaking):

1. New API endpoint: POST /api/partners/deactivate - allows deactivating a single partner by partnerId or tenantId
2. New functions: deactivatePartner() and processPartnerDeactivation()
3. New schema: deactivatePartnerApiSchema
4. Comprehensive tests: End-to-end tests for both partnerId and tenantId flows

Internal Refactoring:

• Extracted common deactivation logic to processPartnerDeactivation() to eliminate code duplication
• Both bulkDeactivatePartners and new deactivatePartner now delegate to this shared processor
• The refactoring maintains all existing functionality (DB updates, audit logs, qstash jobs, etc.)

Architecture Improvements

✅ DRY principle: Deactivation logic centralized in one place
✅ Consistency: Both bulk and single deactivation follow same workflow
✅ Test coverage: New tests verify status changes post-deactivation
✅ API design: Supports both partnerId and tenantId lookups

Minor Observations

The test utility fetchPartner was also added and used to enhance the ban-partner tests to verify status changes, which is a good practice for validation.

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.