Supabase Edge Function 400 s wall clock vs a Sume video job

Supabase Edge Functions have a wall clock limit of 150 seconds on Free and 400 seconds on Paid, so do not hold a function open while a video renders. Submit the job in one function with a webhook URL and return; a second function receives the terminal event.

Supabase numbers are from its limits page, read 2026-10-01. Sume behavior is from Jobs and results and Webhooks.

What are the Supabase limits?

The page lists a wall clock limit of 150 s (Free) and 400 s (Paid), a CPU time limit of 2 s, and a request idle timeout of 150 s. Sume's own wait is shorter than either wall clock, which is why a function should not wait at all.

Why not use Sume's sync mode?

sync waits at most 30 seconds for a terminal state, then returns the same job envelope. A video job often will not be terminal by then, and the docs say that if it is not, poll and do not resubmit. The default async mode returns 202 at once with a status_url, which fits an Edge Function better.

What does the two-function pattern look like?

Function one calls the generate route with mode: "webhook" and a public HTTPS webhook_url pointing at function two, plus an Idempotency-Key, and returns the job_id. Function two verifies the signature and stores the event. Sume sends terminal job events only (job.completed, job.failed, job.canceled).

import { verifyWebhook } from "@sume-com/sdk";

Deno.serve(async (request) => {
  const secret = Deno.env.get("SUME_COM_WEBHOOK_SIGNING_SECRET") || "";
  if (!secret) return new Response("missing secret", { status: 500 });
  const body = await request.text();
  const ok = await verifyWebhook({ body, headers: request.headers, secret });
  if (!ok) return new Response("bad signature", { status: 401 });
  const event = JSON.parse(body);
  // store event.job_id and event.event, then return fast
  return new Response(null, { status: 204 });
});

What if the second function misses an event?

Sume retries up to 10 attempts in total, then leaves a failed delivery while the job still reaches its real state, so keep status_url polling as a backup. The SDK docs say verifyWebhook uses WebCrypto and is importable from Workers, and that an unrecognized event should get a 204, not a 500. Compare the same pattern on AWS Lambda.