Windmill run_wait_result vs a Sume async submit: pick one per job

Windmill advises async mode and offers run_wait_result for short jobs. Sume mirrors that split: async submit plus polling for long work, sync only for short.

5 min readSume
All posts

The answer

Windmill's webhook documentation says it is always better to use asynchronous mode, which returns a job uuid you poll, and to use synchronous mode only for short jobs where blocking is easier. Sume has the same shape: mode: async returns a job to poll, and sync holds the request open for up to wait_timeout_seconds, which ranges from 0 to 30.

For anything that generates media, choose async and read the job later. Sync is for work you expect to finish within the wait.

Side by side

The two platforms name their endpoints differently but follow the same trade-off between holding a connection and polling.

Windmill and Sume execution modes (read 2026-10-03)
AspectWindmillSume
AsyncWebhook returns the job uuidSubmit returns job, status_url, result_url
Syncrun_wait_result returns the script resultmode sync, wait up to 30 seconds
Check laterPoll the get job callGET /v1/jobs/{id}/status
Sync capInstance-level max timeoutwait_timeout_seconds 0 to 30

What to do in a Windmill script

Call Sume from a Windmill script with mode: async, return the job id as the script's result, and let a second script or flow step read the status. That keeps each Windmill run short, so you never depend on the instance's sync timeout, and the work survives your script ending.

If you do want a sync call, set wait_timeout_seconds low and still check the sync block in the response. It reports timed_out, and capacity_exhausted when the API skipped the blocking wait because no waiter capacity was left. In both cases the right move is to poll status_url, not to resubmit.

Idempotency for the retried step

Windmill can rerun a step, and a rerun of a paid submit should not bill twice. Send an Idempotency-Key built from the flow's inputs so the second call returns the first job. Sume reports this on the response as idempotency_hit.

A decision rule

If the answer is needed to continue the same request and the job is short, use sync with a small wait. For everything else, return the job id now and fetch the result later. The deadlines post lists the defaults per job type.

Calling Windmill itself from a Sume callback

The pairing also works the other way. Windmill's async webhook returns a job uuid immediately, so a Sume webhook receiver can trigger a Windmill flow without waiting for it to finish. Answering fast while the real work runs in the background is exactly what async mode is for.

Windmill also lets you stream a flow's progress over SSE by job id. That is useful for your own UI, but Sume sends no progress events, only terminal ones, so do not expect a percentage from the Sume side. Show a spinner until the job is terminal.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume