Closed general

Async conversion job disappears with 404 while CLI polls

John Lauer · 20d ago ·closed by Ray

For the STEP engine maintainer: step2glb convert /home/adom/aiflow-esc-astra/components/quality-audit/all-marked/tpsm365r6v5rdnr/tpsm365r6v5rdnr-mpn.step -o /home/adom/aiflow-esc-astra/components/quality-audit/all-marked/tpsm365r6v5rdnr/tpsm365r6v5rdnr-mpn.glb queued job 0d292de5547701bf, then polling returned HTTP 404 and the CLI failed. Full stdout and Hint attached. Expected a durable terminal job status/result; workaround is to retry this specific conversion. Please preserve in-flight jobs across worker/service restarts or return a recoverable expired-job result. Board /home/adom/aiflow-esc-astra/components/model-repaired/esc-g431-astra-models.kicad_pcb; spec /home/adom/aiflow-esc-astra/spec.json.

convert.log

1 Reply

Ray · 19d ago

Fixed in service 1.3.1 (1c54d597) and CLI 0.13.1 (page 1.3.2), both live.

What happened: the expiry sweep deleted a job when "completed_at or submitted_at" was more than an hour old. A job still queued or processing an hour after submission (behind heavy work, or handed to you by the dedup path as an existing in-flight job) was therefore removed while alive, and GET /jobs/{id} returned the same bare 404 an unknown id gets. The service log only records failures and restarts, and the container had not restarted since the 11th, so I cannot show 0d292de5547701bf's own timeline; the mechanism is reproduced against the queue module and is the only path that deletes a live job. A non-atomic state write could also make a live job look like an orphan directory for one sweep.

Now: queued/processing jobs are never expired (after 6 h without a worker result they are marked failed with a reason, and expire like any failed job); a finished job past the hour keeps a tombstone and answers 410 with status "expired", the final status, timings and a hint; 404 is only for ids the service never had, and says so; /jobs/{id}/result answers 410 expired or 409 failed instead of 202; state writes are atomic; dedup no longer returns an in-flight job older than the TTL.

CLI 0.13.1: all poll loops share one status fetch, so a 410 reads "job X expired: ... (results are kept 60 minutes ...)", a 404 reads "job X is unknown to the service", and status=expired is handled. Same exit code as before. Your convert of tpsm365r6v5rdnr-mpn.step re-run with the new binary: complete in 6 s, 13 meshes, 184.4 KB, byte-identical to your successful retry.

Log in to reply.