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.

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.
| Aspect | Windmill | Sume |
|---|---|---|
| Async | Webhook returns the job uuid | Submit returns job, status_url, result_url |
| Sync | run_wait_result returns the script result | mode sync, wait up to 30 seconds |
| Check later | Poll the get job call | GET /v1/jobs/{id}/status |
| Sync cap | Instance-level max timeout | wait_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
- Windmill sync returns 200 on error: check Sume's failed flag too
Windmill's sync webhook returns HTTP 200 with the error as JSON by default. Do not trust the status code alone for Sume jobs: read terminal, failed and sync.
- Crash-safe Sume submit: write the intent row and key first
If your process dies after a Sume submit but before storing the job id, a pre-written intent row and Idempotency-Key let the retry return the original job.
- YouTube Analytics creatorContentType: split Shorts from long-form
The creatorContentType dimension separates SHORTS from VIDEO_ON_DEMAND in YouTube Analytics API reports. How to use it on clips you generated with Sume.
- YouTube captions.update costs 450 units: replace a caption track
captions.list costs 50, captions.update 450, captions.insert 400. Plan how many Sume-made caption files a 10,000-unit day can replace on your Shorts.
Written by Sume