fix(webapp): IdempotencyKeyConcern honours buffered-run TTL on idempotency expiry

PG-resident path enforces `idempotencyKeyExpiresAt`: when an existing
PG row is found, the lookup compares its `expiresAt` against now,
clears the key on expiry, and lets a new run go through. The buffered
path was missing this — `findBufferedRunWithIdempotency` returned any
buffered run whose snapshot carried the key, regardless of how long
ago the customer's TTL had elapsed. `idempotencyKeyTTL: "2s"` plus
a second trigger 4s later would return the original buffered runId.

Two layers needed the fix:

1. **Read-side (this concern).** Surface
   `idempotencyKeyExpiresAt` on `SyntheticRun` (the snapshot already
   stores it; `findRunByIdWithMollifierFallback` just wasn't exposing
   it). In `findBufferedRunWithIdempotency`, apply the same
   `expiresAt < new Date()` check as the PG path and return null on
   expiry.

2. **Write-side (the buffer's accept dedupe).** Returning null from
   step 1 isn't enough: the trigger pipeline then proceeds to
   `mollifyTrigger`, whose `buffer.accept` Lua dedupes by
   `(envId, taskIdentifier, idempotencyKey)` via SETNX on the same
   `mollifier:idempotency:*` key and would still echo the stale runId
   as `duplicate_idempotency`. On expiry, clear the buffer-side
   idempotency binding via `buffer.resetIdempotency` — the same
   primitive `ResetIdempotencyKeyService` uses for the explicit
   reset-via-API path. The next accept then goes through as a fresh
   trigger.

Verified end-to-end: with mollifier active and
`idempotencyKeyTTL: "2s"`, a same-key retrigger after 4s returns a
new runId; same-key retriggers within the TTL still dedupe to the
original.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: d-cs

apps/webapp/app/runEngine/concerns/idempotencyKeys.server.ts

@@ -92,6 +92,45 @@ export class IdempotencyKeyConcern {
       organizationId,
     });
     if (!synthetic) return null;
+    // PG-resident path enforces idempotency-key expiry below
+    // (`existingRun.idempotencyKeyExpiresAt < new Date()` clears the key
+    // and lets a new run go through). The buffer path needs the same
+    // check — without it a customer who passes `idempotencyKeyTTL: "2s"`
+    // gets the cached buffered runId returned indefinitely, because the
+    // buffer entry persists for its own (hours-long) TTL independent of
+    // the customer's key TTL.
+    //
+    // Returning null isn't enough on its own: the trigger pipeline then
+    // proceeds to `mollifyTrigger`, whose `buffer.accept` Lua dedupes by
+    // `(envId, taskIdentifier, idempotencyKey)` via SETNX on the same
+    // `mollifier:idempotency:*` key and would echo the stale runId as
+    // `duplicate_idempotency`. Clear the buffer-side idempotency
+    // binding (both the lookup and any in-flight claim) so the next
+    // accept goes through as a fresh trigger. Mirrors what
+    // `ResetIdempotencyKeyService` does for the explicit
+    // reset-via-API path.
+    if (
+      synthetic.idempotencyKeyExpiresAt &&
+      synthetic.idempotencyKeyExpiresAt < new Date()
+    ) {
+      const buffer = getMollifierBuffer();
+      if (buffer) {
+        try {
+          await buffer.resetIdempotency({
+            envId: environmentId,
+            taskIdentifier,
+            idempotencyKey,
+          });
+        } catch (err) {
+          logger.warn("IdempotencyKeyConcern: failed to reset expired buffer idempotency", {
+            envId: environmentId,
+            taskIdentifier,
+            err: err instanceof Error ? err.message : String(err),
+          });
+        }
+      }
+      return null;
+    }
     return synthetic as unknown as TaskRun;
   }
 

apps/webapp/app/v3/mollifier/readFallback.server.ts

@@ -44,6 +44,12 @@ export type SyntheticRun = {
   seedMetadataType: string | undefined;
 
   idempotencyKey: string | undefined;
+  // Surfaced for the cached-hit expiration check in IdempotencyKeyConcern.
+  // The PG-resident path enforces this (clears key, allows new run when
+  // expired). For buffered runs the snapshot carries the same field — we
+  // expose it here so the cached-hit branch can apply the same check
+  // rather than indefinitely returning the buffered run's id.
+  idempotencyKeyExpiresAt: Date | undefined;
   idempotencyKeyOptions: string[] | undefined;
   isTest: boolean;
   depth: number;
@@ -178,6 +184,7 @@ export async function findRunByIdWithMollifierFallback(
       seedMetadataType: asString(snapshot.seedMetadataType),
 
       idempotencyKey: asString(snapshot.idempotencyKey),
+      idempotencyKeyExpiresAt: asDate(snapshot.idempotencyKeyExpiresAt),
       idempotencyKeyOptions,
       isTest: snapshot.isTest === true,
       depth: typeof snapshot.depth === "number" ? snapshot.depth : 0,