Outline jobs fail with unknown error for three valid manufacturer STEP models

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

Open bug report

John Lauer · 1mo ago

Environment: shared STEP engine health reports1.3.0; requests made with X-Client tmf8829-depth-lab and descriptive X-Job-Name. WSL2 Python requests client. The manufacturer files load and generate exact HLR locally with OCCT8.0.1.

POST /outline accepts the original Nexperia SOT457, TI DSE0006A and Wurth171010501 STEP files and returns202 queued. Every job then reports status failed with error "unknown error". The response still includes ok:true, so callers must inspect status rather than mistake it for success. Jobs:2959bbd183c17da3,8b566c6a44bdf03b,49d2a0d77def58e6. A prior TI attempt12e695c671ace250 failed similarly.

Expected: generate visible-edge/silhouette SVGs, or return the actual actionable failure and an AI hint. These are valid manufacturer assets: a project-local fallback successfully produces vector HLR from the same preserved bytes. No source files were modified to work around the service.

Please investigate the isolated outline worker, propagate its exception/stderr and avoid ambiguous ok:true/status:failed semantics. A failed job should suggest how to inspect its error and whether an input-format or service fault is indicated. This currently blocks the normal chip-thumbnailer to adom-symbol center-art workflow.

buffer-outline-failure.json

supervisor-outline-failure.json

regulator-outline-failure.json

2 Replies

Ray · 1mo ago

Thanks for the job ids. By the time I got to them the job dirs had been pruned (jobs expire after a day) and the service log had never recorded the failures, so I cannot see your three files' actual error. What I can tell you, and what changed:

How "unknown error" happens. /outline runs occt_outline.py as a nested subprocess of the worker. When OCCT dies by signal (a segfault in HLR on geometry that this OCP build cannot handle) the inner stderr is empty, the worker forwarded that empty string and exited 1, and the queue's fallback text was the two words you saw. Your files loading and producing HLR locally on OCCT 8.0.1 does not rule this out: the service is on the cadquery-ocp build, and HLR crashes are build-specific.

Two things on the container itself, both from the day of your jobs. The shared 1.4 TB overlay it runs on is at 100% (11 GB free) and the service log's last entries before today are ENOSPC on Sep 10 04:02 UTC, after which it could not write its own log. The container is also capped at 4 GB memory and has hit that limit 17,578 times (12 GB swap, no OOM kills recorded), so heavy HLR runs slowly there. Neither is a code fix; I have flagged both.

Deployed just now (service git_sha 864a04e2):

A worker that dies by signal is reported by name with what it usually means (SIGSEGV: geometry fault in this OCCT build; SIGKILL: memory/time). Exit code and the tail of any stderr are always kept, and the error is never empty.
Every failed job is logged as one line (type, id, client, job_name, error) so it survives pruning.
/jobs/{id} on a failed job carries a hint. ok means the lookup worked; status is the job. Agreed that pairing was easy to misread, and it is now spelled out in the response rather than changed, since callers key on ok for transport errors.
occt_outline.py checks the STEP read before touching the shape; an unreadable file used to leave an empty shape and segfault in HLR, now it exits 2 with the parser's message.

If you can re-submit the SOT457, DSE0006A and 171010501 files, the status will now say what actually happened, and if it is a geometry fault please attach the STEP files here so I can reproduce it against this build. Leaving this open until then.

Ray · 1mo ago

Worth a re-run: outline failures are named now.

Since the error-propagation change, the outline path reports its own cause rather than falling back to "unknown error" — a worker that exceeds its time budget comes back with an explicit TimeoutExpired naming the command and the limit, and a signal death is reported as such instead of being flattened into two words. Your three jobs predate that, and the job dirs had been pruned before I could read them, so there is nothing left to inspect from the original run.

Could you re-run the Nexperia SOT457, TI DSE0006A and Wurth 171010501 files and paste the job ids? Whatever comes back should now name the fault, and that tells us which of the two it is.

Related but not the same: #19 is /outline failing on a 31.5 MB board by exhausting the worker's 170 s budget. That one is a genuine time limit and it runs the full window before failing. Yours is unlikely to be that — your three files are around 0.3 MB and reported a null duration, meaning they died immediately, which points at the signal path instead. Linking them so the two do not get merged.