fix: platform billing reschedule usage increment via trigger.dev

[ThyMinimalDev]

What does this PR do?

Fixes a bug where platform billing usage increments were not being properly rescheduled when bookings were moved to a new time. Previously, the rescheduleUsageIncrement task was calling runs.cancel(runId) which would cancel the billing increment entirely, meaning rescheduled bookings would never have their usage tracked.

This PR changes the behavior to use Trigger.dev's runs.reschedule() API, which properly reschedules the delayed task to the new booking time instead of canceling it.

Changes

1. Core fix: Changed runs.cancel(runId) to runs.reschedule(runId, { delay: payload.rescheduledTime }) in the Trigger.dev task
2. Payload update: Moved rescheduledTime from trigger options into the payload so it's available inside the task
3. Type updates: Updated schema and types to include rescheduledTime: Date field with z.coerce.date() validation
4. Consistency: Made options parameter optional and properly forwarded in all tasker methods

Mandatory Tasks (DO NOT REMOVE)

• I have self-reviewed the code (A decent size PR without self-review might be rejected).
• I have updated the developer docs in /docs if this PR makes changes that would require a documentation change. N/A - internal billing logic change.
• I confirm automated tests are in place that prove my fix is effective or that my feature works.

How should this be tested?

1. Create a booking on a platform organization that has async tasker enabled (enableAsyncTasker: true)
2. Reschedule the booking to a new time
3. Verify in Trigger.dev dashboard that the usage increment run is rescheduled (not canceled) to the new booking time
4. Wait for the rescheduled time and verify the usage is incremented correctly

Human Review Checklist

• Verify runs.reschedule() is the correct Trigger.dev API for rescheduling delayed runs
• Confirm the rescheduledTime is correctly passed through: BillingService → PlatformOrganizationBillingTasker → Trigger task
• Consider if integration tests should be added for this billing flow

Checklist

• I have read the contributing guide
• My code follows the style guidelines of this project
• I have checked if my changes generate no new warnings
• My PR is appropriately sized (+24 -16 lines, 6 files)

---

Summary by cubic

Reschedules platform billing usage increment jobs correctly via Trigger.dev by sending rescheduledTime in the payload and using runs.reschedule. Fixes delayed increments when bookings are moved.

• Bug Fixes
  • Pass rescheduledTime in the payload from BillingService (replaces options.delay).
  • Use runs.reschedule(runId, { delay: rescheduledTime }) instead of canceling.
  • Allow optional TriggerOptions in tasker methods and forward to dispatch.
  • Update schema and types to include rescheduledTime (z.coerce.date).

^{Written for commit c0f8844. Summary will update on new commits.}

[cubic-dev-ai]

No issues found across 6 files

[github-actions]

E2E results are ready!

• Workflow #102080.1 latest results

[volnei]

LGTM! Only tests failing...

[cubic-dev-ai]

1 issue found across 1 file (changes from recent commits).

Prompt for AI agents (all issues)

Check if these issues are valid — if so, understand the root cause of each and fix them.


<file name="packages/features/ee/billing/service/proration/__tests__/MonthlyProrationService.integration-test.ts">

<violation number="1">
P2: This test becomes time-dependent by using the current date for `monthKey`, which can make the suite flaky or fail once the current month no longer matches the seeded subscription period. Prefer a fixed date within the test data’s subscription window to keep tests deterministic.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[github-actions]

Devin AI is addressing Cubic AI's review feedback

A Devin session has been created to address the issues identified by Cubic AI.

View Devin Session

[devin-ai-integration]

I reviewed the Cubic AI feedback for this PR. The issue identified was:

Violation #1: The test in MonthlyProrationService.integration-test.ts uses monthKey = "2026-01" which could become time-dependent.

However, after checking all Cubic AI comments on this PR, I could not find a confidence score ("Fix confidence (alpha): X/10") for this issue. Per the instructions to only fix issues with confidence scores of 9/10 or higher, and to skip issues without a confidence score, no changes were made.

Additionally, upon reviewing the code, the monthKey is actually hardcoded to "2026-01" (a fixed date within the subscription window of 2025-06-01 to 2026-06-01), which is already deterministic. The test data's subscription period covers this month, so the test should remain stable.

[volnei]

LGTM