thumbnail-batch async job fails: name 'job_type' is not defined (and CLI does not poll 202)

by adom

The Adom STEP engine: fully manage STEP files. Convert to color-preserving GLB, render thumbnails and vector outlines, laser-etch MPNs, create and edit STEP geometry, extract features, and run molecule mode. One name for the thin Rust CLI and the shared OCCT service. Formerly 'step2glb' + 'service-step2glb'.

Overview Files Skills Discover Packages Releases Dependencies Issues16 Breadcrumbs Pull Requests Activity

Closed general

barrett-land · 2mo ago ·closed by John Lauer

/thumbnail-batch fails for any input large enough to be queued as an async job. The job is accepted, then dies server-side with a Python NameError:

{
  "job_id": "31878e4121c59b78",
  "job_name": "thumbnail-batch",
  "job_type": "thumbnail-batch",
  "status": "failed",
  "size_mb": 1.6,
  "error": "name 'job_type' is not defined"
}

Repro: step2glb thumbnail-batch <a ~1.6 MB .step> --orientations asIs,zDown,yUp --sizes lg -o thumbs

Service v1.2.0 (git_sha 9f579569). The synchronous path is fine — only the queued/async branch is affected, so it looks like a bare job_type reference where the surrounding code uses a different name (e.g. job.job_type / jobtype).

Second, smaller bug in the CLI: thumbnail-batch does not poll async jobs the way convert does. It receives the 202 {"status":"queued","poll":"/jobs/<id>"} and immediately errors out with ERROR: batch thumbnail render failed: service returned HTTP 202, leaving an empty output dir. Even once the server side is fixed, the CLI will need the same polling loop convert already has.

Workaround in the meantime is rendering the GLB locally with three.js + puppeteer.

4 Replies

John Lauer · 2mo ago

Fixed on both sides, thanks for the precise repro.

Server (service 1.2.1, git_sha 8ad7d0d4): your diagnosis was exactly right. A resident-OCP-worker block had been copy-pasted into the thumbnail-batch worker and referenced job_type / type_info, which do not exist in that function's scope, so every queued batch job died with the NameError before doing any work. The block was dead code there (that worker only ever runs thumbnail-batch); it is removed.

CLI (0.12.0, pkg 1.2.0): thumbnail-batch now handles the 202 the same way convert does: it parses job_id, polls /jobs/{id}, downloads /jobs/{id}/result, and unpacks the PNGs. One note: /thumbnail-batch is async for every input now, not just large ones, so pre-0.12.0 CLIs fail on all batch calls against service 1.2.x. Updating the CLI fixes that too.

Verified with your exact repro shape: a 1.3 MB LQFP-100 STEP, --orientations asIs,zDown,yUp --sizes lg. Job queued, polled, 3 PNGs written to the output dir.

Update with adom-wiki pkg install adom/adom-step2glb (binary 0.12.0 via the 1.2.0 release). You can drop the three.js + puppeteer workaround.

John Lauer · 1mo ago

Additional occurrence in step2glb features CLI 0.12.0, Linux WSL2, 9 September 2026. A manufacturer SOT457 STEP (263744 bytes, SHA-256 0c95a3ba13d15b20c0d03fd8f85580d5eff01642503c57909016fef54634b8e4) produced ERROR: feature extraction failed: service returned HTTP 202 and a generic health-check hint, while the returned job 698e5ec395d19858 subsequently completed successfully in 2.6 seconds.

I recovered the result by polling that same job and retrieving its JSON. No repeat submission was needed. The ordinary convert command successfully polled its separate job. Please apply async polling/artifact retrieval consistently to features as well as thumbnail-batch, and return job-aware AI hints that distinguish queued/running from failed. Pin-1 extraction returned unknown; this is a separate geometry limitation and should remain explicit.

features-job-status.json

John Lauer · 1mo ago

Additional live reproduction: step2glb CLI 0.12.0, service 1.3.0 (d7645163), WSL2 Linux, 9 September 2026.

The single-thumbnail command also exits with code 4 on a successful asynchronous submission:

step2glb thumbnail SOT457.step --pose top --up-axis yUp --width 1100 --height 850 -o SOT457-manufacturer-top.png
ERROR: thumbnail render failed: service returned HTTP 202: {"ok":true,"job_id":"f0fb9cea93bc842f","status":"queued",...}

Polling that same job showed status:complete, 2.6 seconds, 8447 result bytes. Downloading its result recovered the PNG without resubmission. The current CLI's health hint incorrectly frames an accepted job as rendering failure. Please use the same 202 poll/download handling for single thumbnail and features, preserve the job ID on interruption, and recognize complete as terminal success.

The attached image is also a side-on package view despite requesting top with source +Y up. Metadata independently reports Y as the package's thin axis. This orientation symptom needs service-side investigation; I have not established its cause. Retained exact manufacturer source SHA-256: 0c95a3ba13d15b20c0d03fd8f85580d5eff01642503c57909016fef54634b8e4.

SOT457-manufacturer-top

SOT457-top-thumbnail-job-status.json

Ray · 1mo ago

Additional reproduction on step2glb CLI 0.12.0; service 1.3.0 d76451638fdc9d0f3914b7c6d0038ea06aaaf925; Linux/WSL2: the single-file step2glb thumbnail board.step --width 1600 --height 1000 command also treats a valid HTTP 202 queued job as failure instead of polling. This is not limited to thumbnail-batch. A submitted single-file job completed successfully and its PNG could be retrieved manually. Please cover both commands in the polling fix. This thread uses the native Babylon GLB renderer as its local workaround; no upstream PR is in progress here.