feat(webapp): enforce watch plan limits

[kathiekiwi]

What & why. Watches now honour a plan's watch limits. A watch whose window exceeds the plan's agentWatchMaxHours, or that would push the org past its agentWatchers count, is refused with a new watch_limit_reached result and an upgrade hint (a chat line on the card, HTTP 409 on the API).

Key decisions.

• Plan limits are a floor below the existing code ceilings: min(plan, WATCH_MAX_HOURS=24) for the window, and the per-chat cap of 3 still applies independently. Plans only tighten, never loosen.
• Watcher count is org-wide and checked only after the immediate check declines, so a one-shot consumes no slot.
• Fails open: an absent limit resolves to the unlimited sentinel, so self-hosted is unaffected; the upgrade nudge is gated on isBillingConfigured().
• Follow-up: quiet Pro-mark on the card's long-window options.

TRI-12863

[changeset-bot]

⚠️ No Changeset found

Latest commit: aced730

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 555ad2fe-3c5b-4d37-98f7-b72ccafabda3

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

Walkthrough

The pull request adds plan-based limits for dashboard agent watches. It limits watch duration and organization-wide active watches, adds billing-aware refusal messages, and maps limit refusals to HTTP 409. It also adds sweep-attempt persistence for stale investigations. Failed settlements are retried up to five times before force abandonment as inconclusive. Integration tests cover both watch-limit enforcement and poison-investigation handling.

🚥 Pre-merge checks | ✅ 3 | ❌ 2

❌ Failed checks (2 warnings)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The description explains the change and key decisions but omits the required checklist, testing, changelog, and screenshots sections.	Add the template sections, complete the checklist, document test steps, provide a changelog entry, and state whether screenshots are applicable.
Docstring Coverage	⚠️ Warning	Docstring coverage is 27.27% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely describes the main change: enforcing watch plan limits.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches 💡 2

📝 Generate docstrings 💡

• Create stacked PR
• Commit on current branch

🛠️ Fix failing CI checks 💡

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/agent-watch-limits-tri-12863

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[pkg-pr-new]

Open in StackBlitz

@trigger.dev/build

npm i https://pkg.pr.new/@trigger.dev/build@d4bda0a

trigger.dev

npm i https://pkg.pr.new/trigger.dev@d4bda0a

@trigger.dev/core

npm i https://pkg.pr.new/@trigger.dev/core@d4bda0a

@trigger.dev/python

npm i https://pkg.pr.new/@trigger.dev/python@d4bda0a

@trigger.dev/react-hooks

npm i https://pkg.pr.new/@trigger.dev/react-hooks@d4bda0a

@trigger.dev/redis-worker

npm i https://pkg.pr.new/@trigger.dev/redis-worker@d4bda0a

@trigger.dev/rsc

npm i https://pkg.pr.new/@trigger.dev/rsc@d4bda0a

@trigger.dev/schema-to-json

npm i https://pkg.pr.new/@trigger.dev/schema-to-json@d4bda0a

@trigger.dev/sdk

npm i https://pkg.pr.new/@trigger.dev/sdk@d4bda0a

commit: d4bda0a

[devin-ai-integration]

Devin Review found 1 new potential issue.

[devin-ai-integration]

🟡 Users who upgrade are still told to upgrade before creating a watch, for up to ten minutes

The org's watch allowance is read from a cache that is never cleared when the plan changes (platformCache.limits.swr at apps/webapp/app/services/platform.v3.server.ts:511), so a customer who follows the upgrade prompt keeps getting the same refusal until the cached value ages out.
Impact: After paying to upgrade, a user can be blocked from creating watches — and shown "Upgrade your plan for more" again — for up to ten minutes.

Why the plan change doesn't reach the watch limit read

resolveWatchPlanLimits (apps/webapp/app/services/dashboardAgentWatchLimits.server.ts:34-43) reads both floors through getCachedLimitAllowingZero, which stores under ${orgId}:${limit}:allow-zero in the limits namespace (fresh 5 min, stale 10 min, see apps/webapp/app/services/platform.v3.server.ts:172-176).

setPlan invalidates plan-derived caches on every successful plan change (apps/webapp/app/services/platform.v3.server.ts:587), but invalidatePlanDerivedCaches only removes entitlement and ssoEntitlement (apps/webapp/app/services/platform.v3.server.ts:226-229); nothing ever calls platformCache.limits.remove. The refusal in createDashboardAgentWatch (apps/webapp/app/services/dashboardAgentWatches.server.ts:357-374) therefore keeps using the pre-upgrade limits. This was harmless for the existing getCachedLimit callers (concurrency defaults), but this PR makes the stale value directly user-facing behind an explicit "Upgrade your plan" call to action.

Prompt for agents

The watch plan floors are read via getCachedLimitAllowingZero, which caches under the `limits` namespace with a 5 min fresh / 10 min stale window. No code path ever removes entries from that namespace: invalidatePlanDerivedCaches in apps/webapp/app/services/platform.v3.server.ts only clears `entitlement` and `ssoEntitlement`, even though it is called after every successful plan change in setPlan. As a result, an org that upgrades in response to the new 'Upgrade your plan for more' hint from dashboardAgentWatchLimits.server.ts keeps hitting the old, tighter watch limits until the cache expires. Consider extending the plan-change invalidation so the limit keys used by the watch floors (both the plain `${orgId}:${limit}` and the new `${orgId}:${limit}:allow-zero` variants) are removed when a plan changes, or otherwise ensure the watch limit read observes a plan change promptly.

---

Was this helpful? React with 👍 or 👎 to provide feedback.