fix: resolve task TTL even when queue is overridden

When a caller provides a custom queue name (via options.queue), the queue
concern returned early without looking up the task's TTL. This caused
task-level and config-level TTL to be silently ignored in favor of just
the dev default. Now both the locked-worker+custom-queue and non-locked+
custom-queue paths fetch task TTL via minimal select queries.

https://claude.ai/code/session_01Swj2TA2crHC29m1ynWwEUN

Author: claude

apps/webapp/CLAUDE.md

@@ -61,7 +61,7 @@ Some services (e.g., `cancelTaskRun.server.ts`, `batchTriggerV3.server.ts`) bran
 
 The `triggerTask.server.ts` service is the **highest-throughput code path** in the system. Every API trigger call goes through it. Keep it fast:
 
-- **Do NOT add database queries** to the trigger path. The only acceptable DB query for task defaults (TTL, etc.) is the single existing `backgroundWorkerTask.findFirst()` call with a minimal `select`.
+- **Do NOT add database queries** to the trigger path. Task TTL is resolved via the queue concern's existing `backgroundWorkerTask.findFirst()` calls. When a custom queue override is provided, a minimal `select: { ttl: true }` fallback query fetches the task's TTL separately — this is acceptable because custom queue overrides are rare.
 - **Two-stage resolution pattern**: Task metadata is resolved in two stages by design:
   1. **Trigger time** (`triggerTask.server.ts`): Only TTL is resolved from task defaults. Everything else uses whatever the caller provides.
   2. **Dequeue time** (`dequeueSystem.ts`): Full `BackgroundWorkerTask` is loaded and retry config, machine config, maxDuration, etc. are resolved against task defaults.

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

@@ -99,6 +99,13 @@ export class DefaultQueueManager implements QueueManager {
         // Use the validated queue name directly
         queueName = specifiedQueue.name;
         lockedQueueId = specifiedQueue.id;
+
+        // Still need task TTL even when queue is overridden
+        taskTtl = await this.getTaskTtl(
+          request.taskId,
+          request.environment.id,
+          lockedBackgroundWorker.id
+        );
       } else {
         // No specific queue name provided, use the default queue for the task on the locked worker
         const lockedTask = await this.prisma.backgroundWorkerTask.findFirst({
@@ -183,7 +190,9 @@ export class DefaultQueueManager implements QueueManager {
     // Use extractQueueName to handle double-wrapped queue objects
     const queueName = extractQueueName(queue);
     if (queueName) {
-      return { queueName };
+      // Still need task TTL even when queue is overridden
+      const taskTtl = await this.getTaskTtlForEnvironment(taskId, environment);
+      return { queueName, taskTtl };
     }
 
     const defaultQueueName = `task/${taskId}`;
@@ -233,6 +242,33 @@ export class DefaultQueueManager implements QueueManager {
     return { queueName: task.queue.name ?? defaultQueueName, taskTtl: task.ttl };
   }
 
+  private async getTaskTtl(
+    taskId: string,
+    environmentId: string,
+    workerId: string
+  ): Promise<string | null | undefined> {
+    const task = await this.prisma.backgroundWorkerTask.findFirst({
+      where: {
+        workerId,
+        runtimeEnvironmentId: environmentId,
+        slug: taskId,
+      },
+      select: { ttl: true },
+    });
+    return task?.ttl;
+  }
+
+  private async getTaskTtlForEnvironment(
+    taskId: string,
+    environment: AuthenticatedEnvironment
+  ): Promise<string | null | undefined> {
+    const worker = await findCurrentWorkerFromEnvironment(environment, this.prisma);
+    if (!worker) {
+      return undefined;
+    }
+    return this.getTaskTtl(taskId, environment.id, worker.id);
+  }
+
   async validateQueueLimits(
     environment: AuthenticatedEnvironment,
     queueName: string,