← Files KreaARCHIVED FILE
skills/krea-generate/references/progress-reporting.md
1.75 KB · Oct 3, 2026 · 06:03 UTC
# Progress Reporting Use this reference during async polling for any job expected to run longer than 30 seconds, especially video generation, LoRA training, and large batches. ## Rule While polling, send the user one concise progress ping about every 30 seconds: ```text Still processing at <elapsed>m / ~<expected>m total. I will ping when it finishes or if anything goes wrong. ``` The 2026-05-17 production session went 30+ minutes with silent polling. That silence damaged trust more than the failed output did. Never repeat it. ## Cadence - Ping immediately when a job enters a new visible state: `queued`, `processing`, `completed`, `failed`, or `cancelled`. - During a long unchanged state, ping every 25-35 seconds. - Do not ping more often than every 25 seconds unless the status changed or the user asked. - For multiple parallel jobs, aggregate in one line instead of sending one message per job. ## MCP Loop Call `get_job(jobId=<id>)`, inspect the status, sleep roughly 20 seconds, and repeat until terminal. Ping the user on status changes and every 25-35 seconds during unchanged processing. ## What to Say Good: - `Queued: video job submitted. Expected 10-15 minutes.` - `Still processing at 6m / ~12m total. I will keep checking.` - `Completed. Downloading and checking frames now.` - `Failed after 4m. I am checking the error before deciding whether to retry.` Bad: - Raw job IDs without context. - Full JSON dumps. - Repeated "still working" every few seconds. - Silence for a long poll loop. ## On Delay If a video job remains queued for more than 5 minutes, tell the user it is likely capacity-related and ask whether to keep waiting or stop. If a job exceeds the workflow's expected upper bound by more than 50%, explain the delay before continuing to poll.
SHA-256: 64c0795e9e831d553ac60ee8ba2f482ee67791a7828c149dbe23e6650479b74d