No progress percent in Sume job events: what to log and show instead

GET /v1/jobs/{id}/events returns a public timeline made of eight event names, and none of them is a percentage. Job webhooks are terminal-only too, with no progress or partial deliveries. So a progress bar cannot be driven by Sume data; log the events for debugging and show state, not a number.

That is a product decision as much as a technical one: a fake percentage that stalls at 90 percent annoys users more than an honest "working".

The eight events

From the jobs and results page. Public events do not show raw provider task ids or raw provider URLs.

What to show

Three states cover almost every screen: waiting (queued), working (started), and ready. Add elapsed time since job.created, which you can compute yourself and is true. Do not add a countdown or an estimate that Sume has not given you; it does not publish a queue position or an ETA.

The status payload also carries next_poll_after_seconds while a job is in flight and cancelable, and cancel is possible only until job.started.

• Queued: "Waiting for a free slot".
• Started: "Rendering; this can take minutes".
• Completed: show the clip and the cost from the usage object.
• Failed: show the next action from the error, not the raw text.

What to log

Store the event names with timestamps beside your job row. It gives you a queue-wait and run-time split you can chart per model without any extra API. If the receiver misses a webhook, the webhook.delivery events show whether Sume tried, and the same timeline is the first thing support asks for.

curl -s https://api.sume.com/v1/jobs/$JOB_ID/events \
  -H "Authorization: Bearer $SUME_API_KEY"

Reading events for recovery

The events endpoint is also a recovery tool. If a webhook never arrived, the timeline shows whether the job reached a terminal event and whether a delivery was attempted, and you can then read the result from the job record.

If a stakeholder asks for a progress bar anyway, offer an indeterminate one with elapsed time. It is truthful, it costs nothing, and it does not promise an end time that a queue and a model run can break.

Do not parse events for state in a hot loop; the status endpoint is built for polling and tells you when to come back. Use events when you debug a single job or build a post-mortem view.

• Poll status, read events for debugging.
• Never display provider names; public events do not carry them.
• Keep event names as constants, not free text, in your own logs.