n8n 3.0 Chat Trigger WebSocket frames: replying with a Sume job

In n8n 3.0, Chat Trigger WebSocket frames are all JSON with a type field, with the values heartbeat, continue, error and message (n8n 3.0 breaking changes, read 2026-10-02). If a chat workflow starts a Sume video job, reply with the job id and let a later message carry the result; do not hold the chat open for a render.

What the vendor says

If you built a custom chat client against the older frame format, 3.0 is the point to update it.

Where Sume fits

Sume's default async mode returns 202 and a job id at once. The sync mode waits at most 30 seconds on the HTTP call, and the docs say video, avatar-video and face-swap jobs routinely exceed that. So a chat turn that submits video should answer quickly with something like the job id, not wait.

Two workable shapes

• Reply, then notify: the first turn submits the job with a webhook_url and replies that the video is on its way. A second workflow, triggered by the signed Sume webhook, posts the result to the user in whatever channel you use.
• Reply, then ask again: the first turn stores the job_id; the user's next message triggers a status read and returns the result if the job is terminal.

Cost and safety

Because each chat message is an execution, a user who sends "are you done?" ten times costs ten executions. Reading GET /v1/jobs/{job_id}/status is cheap and never resubmits paid work. Use an Idempotency-Key on the submit so a repeated message cannot create a second job.

Sume does not stream progress over WebSocket or SSE; the events endpoint is a pull snapshot. Do not promise a live progress bar in the chat.