n8n 3.0 task runner timeout 60s: Sume polling in Code nodes

If a Code node in your n8n workflow loops until a Sume video job finishes, it will start failing on n8n 3.0. The 3.0 breaking-changes page lists N8N_RUNNERS_TASK_TIMEOUT dropping its default from 300 seconds to 60, so a long-running task is killed at one minute. A generated video usually takes longer than that, so the loop has to leave the Code node.

The fix is to stop holding a task open. Submit the job in one step, return immediately, and let a webhook or a Wait node bring you back when the result exists.

What changed in n8n 3.0

The n8n page is dated as an October 2026 release. Two lines matter for Sume workflows: the shorter runner timeout, and the removal of the legacy HTTP Request Tool in favour of the HTTP Request node wired into an AI Agent's Tool input.

Why a polling loop in a Code node breaks

Sume jobs are asynchronous by default: the create call returns 202 with a job id, and you read GET /v1/jobs/:id/status and /result later. In sync or subscribe mode the server waits at most 30 seconds via wait_timeout_seconds and then hands you back a job to poll. Neither mode promises completion inside a 60 second task.

The dangerous part is what a timeout means. Killing your Code node does not cancel the job. The docs state that a client-side timeout leaves the job running and billing. If the retry logic then resubmits the create call, you pay twice.

Three patterns that fit the 60 second ceiling

Pick one and keep the Code node to a few seconds of work.

• Webhook mode: create the job with webhook mode and a public HTTPS URL, finish the execution, and let a second workflow with a Webhook trigger receive job.completed, job.failed or job.canceled.
• Wait node: after the create call, use a Wait node, then one HTTP Request to /status, then an IF on the state. Use the next_poll_after_seconds value Sume returns rather than a fixed guess.
• Idempotency-Key on every create: send a stable key per business event so an n8n retry returns the original job. Reusing the key with a different body gives 409 idempotency_conflict.

Verify the webhook before you trust it

Sume signs each delivery with HMAC-SHA256 over <timestamp>.<raw_body> and sends x-sume-webhook-timestamp and x-sume-webhook-signature: sume-v1=<hex>. During a 24 hour secret rotation the header can carry more than one comma-separated entry, so compare against each. The sample below refuses an empty secret.

Deliveries retry up to 10 times with a 10 second timeout per attempt, so answer fast and dedupe on job_id. Polling stays available as a backup if your n8n instance was down.

import hashlib
import hmac
import os
import time


def verify(raw: bytes, ts: str, sig_header: str, secret: str) -> bool:
    if not secret:
        raise ValueError("signing secret is empty")
    if abs(time.time() - int(ts)) > 300:
        return False
    mac = hmac.new(secret.encode(), ts.encode() + b"." + raw, hashlib.sha256)
    want = "sume-v1=" + mac.hexdigest()
    return any(hmac.compare_digest(p.strip(), want) for p in sig_header.split(","))


if __name__ == "__main__":
    secret = os.environ.get("SUME_COM_WEBHOOK_SIGNING_SECRET", "")
    body = b'{"ok":true}'
    ts = str(int(time.time()))
    sig = "sume-v1=" + hmac.new(secret.encode(), ts.encode() + b"." + body, hashlib.sha256).hexdigest()
    print(verify(body, ts, sig, secret))

Checklist before upgrading

Search your workflows for Code nodes that contain a while loop or a sleep around a Sume call. Replace each with one of the patterns above, then upgrade. If you must keep a longer task, raise N8N_RUNNERS_TASK_TIMEOUT explicitly, but treat that as a stopgap: the job still outlives the task.