MCP create and Builtin calls can time out before returning the Assembly ID #602

Why

On 2026-10-20, ChatGPT ran a Builtin shortcut through the hosted @transloadit/mcp-server (0.7.2) with waiting enabled: Video covers, using a 239 MB file from Wikimedia as a URL input. The tool call outlived ChatGPT's tool-call deadline, and ChatGPT reported "Transloadit timed out before returning a result or an Assembly ID". It then retried in background mode and created a second Assembly. The first Assembly kept running with nobody following it, so the customer paid for both.

Cause

• wait_for_completion without wait_timeout_ms hands the SDK its default of one day, so transloadit_create_assembly and the Builtin shortcuts can block far past the roughly 60 seconds that hosts like ChatGPT allow for a tool call. transloadit_wait_for_assembly has the same unbounded default.
• When the SDK's polling timeout does fire, it throws PollingTimeoutError, and the tool reports an error instead of the Assembly it already created.
• Builtin Templates take uploads (:original) and have no /http/import Step, so a URL input is first downloaded to the MCP server's disk. That download (up to 10 minutes) happens before the Assembly is created, so no Assembly ID exists while it runs. Uploading the file with upload_behavior: await adds more time.

Repro

1. Call transloadit_video_covers (or transloadit_create_assembly with a Template whose input is :original) with a large public URL in files and wait_for_completion: true.
2. Watch the call run for minutes: first the download, then the tus upload, then polling.
3. A host with a tool-call deadline abandons the call without an Assembly ID and may retry it.

Expected

• A create, resume, Builtin or wait call returns the Assembly ID, status URL and current state well within host deadlines (about 45 seconds by default, configurable), even when processing takes longer.
• That result clearly says the Assembly is still running and that transloadit_wait_for_assembly or transloadit_get_assembly_status can follow it. The result widget renders it as running.
• A polling timeout returns the known Assembly instead of an error.
• A slow URL download does not hold back the Assembly: it is created first and receives the file when the download finishes.
• Upload flows (expected_uploads, tus) keep working.

_{🤖 Claimed by kvz on framework1/node-sdk since 2026-10-20 · resume: claude --resume 26eaa88e-b3fa-4cc1-bcce-0c7ff5b6bab7}