Decart Lucy queue times out at 10 minutes; Sume job statuses

Decart's Python queue API reports a Lucy job as failed when it fails or times out after 10 minutes. Sume has no such client-side timeout in its docs: a job is queued, processing, completed, failed, or canceled, and you either poll with exponential backoff or ask for a webhook. The practical rule is the same on both: persist the job id before you wait.

Decart's details come from its Python Queue API page and the non-realtime overview, read 2026-10-02. Sume's come from Jobs and results.

What does Decart's queue return?

The Python SDK has four methods: submit() returns a job id immediately, status() checks progress, result() retrieves the completed video, and submit_and_poll() does all of it in one call. Statuses are pending, processing, completed, and failed; the page says failed covers both a failure and a timeout after 10 minutes. A result carries status, data (video bytes), and error. The supported models are lucy-2.1, lucy-vton-3.5, and lucy-restyle-2.

The page does not say how long finished videos are retained, and this post will not guess.

How does Sume report the same thing?

Poll GET /v1/jobs/{id}/status with exponential backoff and stop on completed, failed, or canceled. Fetch the output from GET /v1/jobs/{id}/result once it is complete; before that the API returns a conflict rather than an empty result. The docs say plainly not to resubmit a paid request because a local process timed out, which is the failure mode a client-side timeout invites.

Cancellation only works before generation starts. After that the API returns 409 job_generation_already_started and the job runs to completion.

JOB=job_123
while true; do
  S=$(curl -s https://api.sume.com/v1/jobs/$JOB/status \
    -H "Authorization: Bearer $SUME_API_KEY" | jq -r .sume_status)
  case "$S" in
    completed|failed|canceled) break ;;
  esac
  sleep 10
done
echo "final status: $S"
curl -s https://api.sume.com/v1/jobs/$JOB/result \
  -H "Authorization: Bearer $SUME_API_KEY"

Does the loop above handle failure?

Yes, to a point. It exits on any of the three terminal statuses, then fetches the result. If the final status was failed or canceled, the result call answers 409 job_not_completed instead of a video, so branch on $S before you treat the output as usable. A production version also grows the sleep with each pass (exponential backoff, as the docs advise) instead of a flat 10 seconds, and stops after a ceiling you choose.

The ceiling is where Decart's built-in 10-minute timeout and Sume's open-ended jobs differ most. Decart decides for you that 10 minutes is too long. On Sume you decide, and the docs tell you the safe response to a slow job: keep waiting or read its events, never submit a second paid request.

When is a webhook better than polling?

For clips that take minutes, a webhook means no loop at all. Sume generation submits accept a mode of async, sync, subscribe, or webhook, and webhook needs a public HTTPS webhook_url, as the face-swap page describes. Keep a status poll as a backup, because a receiver can be down when a delivery arrives; the webhooks page covers delivery.

What should a migration keep in mind?

Map the states in the table, store the job id as soon as submit returns, and never let a local timeout trigger a second paid submit. If a Sume job is slow, read its events at GET /v1/jobs/{id}/events before deciding anything.

One more difference: Decart's submit_and_poll() hides the loop. If you used it, your migration is not a one-line swap, because Sume's flow is submit, then status, then result, with the three calls under your control. That is more code, and it is also what lets you survive a process restart, since the job id is durable.