meshprobe open on a glTF that Blender's importer rejects (a SolidWorks-exported GLB with a TEXCOORD_0 accessor whose count differs from POSITION) hangs for the full DEFAULT_WORKER_TIMEOUT_SECONDS (180 s) and then reports Invalid value: timed out, although the worker had already raised and answered within ~5 s.
Driving blender/worker.py by hand over stdin shows why: Blender prints the operator failure (Error: Python: Traceback ...) from its C side without a trailing newline, so the worker's emit(...) JSON reply lands on the same stdout line:
[ 4.7] File "...\io_scene_gltf2\blender\imp\mesh.py", line 359, in do_primitives
[ 4.7] uvs = uvs[indices]
[ 4.7] IndexError: index 576 is out of bounds for axis 0 with size 576
[ 4.7] 00:04.609 bpy.rna | ERROR Python script error in IMPORT_SCENE_OT_gltf.execute
[ 4.7] Error: Python: Traceback (most recent call last):
...
[ 4.7] File "...\blender_gltf.py", line 41, in create <...>{"error":{"code":"worker.RuntimeError","message":"Error: Python: Traceback ...
BlenderController._wait_for does json.loads(line) per line, so that line fails to parse, goes to _logs, and the controller waits until the timeout.
Repro / environment
- meshprobe 1.2.0 (PyPI), Blender 5.2.1 LTS, Windows 11.
- Any
.glb where a primitive's TEXCOORD_0 count != POSITION count (SolidWorks 2026 SaveAs3 produces these on textured faces); a sanitized copy of the same file (attribute dropped) opens in ~13 s.
- Standalone:
blender -b --python-expr "import bpy; bpy.ops.import_scene.gltf(filepath=r'bad.glb')" fails in ~4 s with the same IndexError.
Local workaround that fixes it for me: emit() printing an empty line first (print(flush=True)) so every reply starts on a fresh line — the bad file then fails in 6 s with the importer's message. A more robust variant would be for the controller to look for a JSON object at the end of a line (or a sentinel prefix) rather than requiring the whole line to be JSON. Might also be worth surfacing the worker's non-JSON _logs in the timeout message so the Blender traceback is visible.
meshprobe openon a glTF that Blender's importer rejects (a SolidWorks-exported GLB with aTEXCOORD_0accessor whose count differs fromPOSITION) hangs for the fullDEFAULT_WORKER_TIMEOUT_SECONDS(180 s) and then reportsInvalid value: timed out, although the worker had already raised and answered within ~5 s.Driving
blender/worker.pyby hand over stdin shows why: Blender prints the operator failure (Error: Python: Traceback ...) from its C side without a trailing newline, so the worker'semit(...)JSON reply lands on the same stdout line:BlenderController._wait_fordoesjson.loads(line)per line, so that line fails to parse, goes to_logs, and the controller waits until the timeout.Repro / environment
.glbwhere a primitive'sTEXCOORD_0count !=POSITIONcount (SolidWorks 2026SaveAs3produces these on textured faces); a sanitized copy of the same file (attribute dropped) opens in ~13 s.blender -b --python-expr "import bpy; bpy.ops.import_scene.gltf(filepath=r'bad.glb')"fails in ~4 s with the same IndexError.Local workaround that fixes it for me:
emit()printing an empty line first (print(flush=True)) so every reply starts on a fresh line — the bad file then fails in 6 s with the importer's message. A more robust variant would be for the controller to look for a JSON object at the end of a line (or a sentinel prefix) rather than requiring the whole line to be JSON. Might also be worth surfacing the worker's non-JSON_logsin the timeout message so the Blender traceback is visible.