feat(webapp): mollifier trigger-time decisions — mollify, claim, read fallback

[d-cs]

Summary

The trigger hot path's mollifier integration:

• mollifyTrigger: when the gate trips, write the engine.trigger snapshot to the buffer and return a synthesised QUEUED response. Postgres write is deferred to drainer-replay (next PR in the stack).
• Pre-gate idempotency-key claim: same-key triggers serialise through Redis so a burst lands in PG / buffer exactly once.
• Read-fallback extensions: findRunByIdWithMollifierFallback for the trigger-time idempotency lookup that must see buffered runs.
• Gate bypasses: debounce, oneTimeUseToken, parentTaskRunId/triggerAndWait skip the mollify path entirely.
• triggerTask + IdempotencyKeyConcern wired to the above.

All behaviour gated by the master TRIGGER_MOLLIFIER_ENABLED switch; off-state hot path is unchanged (the gate is not even consulted).

Stacked on the buffer extensions PR.

Test plan

• `pnpm run typecheck --filter webapp` passes
• `pnpm run test --filter webapp test/mollifierMollify.test.ts` passes
• `pnpm run test --filter webapp test/mollifierIdempotencyClaim.test.ts` passes
• `pnpm run test --filter webapp test/mollifierReadFallback.test.ts` passes
• `pnpm run test --filter webapp test/mollifierGate.test.ts` passes
• `pnpm run test --filter webapp test/engine/triggerTask.test.ts` passes

---

Ship-gate follow-up fixes

• Batch items bypass the mollifier gate — fixes BatchTaskRunItem_taskRunId_fkey FK violation on batch triggers when the gate trips. End-state is a drainer-side BatchTaskRunItem create-on-materialise; batch traffic passes through the gate until that lands.
• IdempotencyKeyConcern honours buffered-run TTL on expiry — buffered path now clears expired idempotency claims (read-side) and resets the buffer's mollifier:idempotency:* SETNX binding (write-side) so a re-trigger past the customer's TTL lands as a fresh run instead of echoing the stale buffered runId.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 44286e0

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

Run ID: 0f4e39c1-96a6-4924-a0f4-97bb0b89551a

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

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch mollifier-phase-3-trigger

---

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 and usage tips.}

[d-cs]

Pushed 2 follow-up fixes:

• Batch items bypass the mollifier gate. Without this, batch triggers crash with BatchTaskRunItem_taskRunId_fkey FK violations as soon as the gate trips. The mollify path returns a stripped run-shape with no PG row, but BatchTaskRunItem.taskRunId is a NOT NULL FK to TaskRun.id and the join row is created at trigger time. End-state is a drainer-side BatchTaskRunItem create-on-materialise (snapshot already carries batch: { id, index }), but until that lands, batch triggers pass through — they lose the burst-protection benefit, but the path is end-to-end correct.
• IdempotencyKeyConcern honours buffered-run TTL on expiry. The PG-resident path enforced `idempotencyKeyExpiresAt` by clearing the key on expiry; the buffered path was missing this and would return the original buffered runId indefinitely (`idempotencyKeyTTL: "2s"` plus a second trigger 4s later still got the cached run). Fix touches both read-side (surface `idempotencyKeyExpiresAt` on `SyntheticRun`, apply `< new Date()` check in `findBufferedRunWithIdempotency`) and write-side (clear the buffer's idempotency lookup via `buffer.resetIdempotency` on expiry so the next accept goes through as a fresh trigger).

Verified end-to-end against a buffered run; webapp typecheck clean.

[devin-ai-integration]

Devin Review found 2 new potential issues.

View 14 additional findings in Devin Review.

[devin-ai-integration]

🚩 Request-level idempotency (x-trigger-request-idempotency-key) is degraded for mollified runs

When a trigger is mollified, result.run.id is a synthetic ID from RunId.fromFriendlyId() that doesn't correspond to a PG row. The route handler (api.v1.tasks.$taskId.trigger.ts:137) calls saveRequestIdempotency(requestIdempotencyKey, 'trigger', result.run.id). On an SDK retry (lost HTTP response), handleRequestIdempotency finds this cached ID but prisma.taskRun.findFirst({ where: { id: cachedRequestId } }) returns null (no PG row), so it falls through to a fresh trigger attempt.

For triggers WITH a task-level idempotency key, the retry is still correctly deduplicated via the buffer's lookupIdempotency SETNX in findBufferedRunWithIdempotency (idempotencyKeys.server.ts:171-181). For triggers WITHOUT a task-level idempotency key, a lost-response retry during the buffer window could produce a duplicate buffer entry. This is a narrow edge case (requires lost response + no idempotency key + buffer window) and is bounded by the drainer's eventual materialization.

---

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

[d-cs]

Fixed in 44286e0 on the trigger branch. Surfaced the divert as a typed isMollified?: boolean on TriggerTaskServiceResult (with a comment block explaining the contract), and the route now gates saveRequestIdempotency on !result.isMollified. Lost-response retries during the buffer window are accepted as fresh triggers; task-level idempotency keys still dedupe via the buffer SETNX, and the behaviour is bounded by drainer materialisation as you noted. Regression locked by two new assertions in triggerTask.test.ts — mollify path asserts isMollified === true, pass-through asserts it's falsy.