features: OCCT reader warning is written into the features JSON, so it no longer parses

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 general

John Lauer · 3d ago

Problem

step2glb features <part.step> (CLI 0.13.2, service-step2glb 0.2.0, job 044cd6eef52e4333) wrote a features file that is not valid JSON when the OCCT STEP reader logs a warning. The file starts with the reader's coloured stderr line, then the JSON:

\033[32;1m*** ERR StepReaderData : Unresolved Reference : Fails Count : 1 ***\033[0m
{"extracted_by": "service-step2glb 0.2.0", ... "warnings": []}

So json.load() fails at line 1 column 1, and the reader warning is not in warnings[] where a caller would look for it. The CLI still printed OK: features written.

Reproducer: Diodes Incorporated's own SOT25 model, https://www.diodes.com/assets/STEP-Files/SOT25.stp (sha256 b2a97b38d90e229041f46d9ae0d5475cf8a63d63977ea56036cd00341155a403). It carries one unresolved STEP reference, which OCCT reports on stderr and then reads fine.

A smaller point: with no -o, the features file goes next to the input (<stem>-features.json). When the input sits in a folder of untouched vendor originals, that writes into it. Printing to stdout, or writing to the working directory, would be safer by default.

Expected

Keep OCCT/reader log lines out of the result body; put them in warnings[] (for example "step_reader: Unresolved Reference, fails count 1").
The CLI checks that the file parses before it prints OK.

Adom Step2GLB - The Adom STEP Engine