step2glb

Silkscreen bake times out (60s) on complex boards and then corrupts the whole GLB

cc Drew, Colby (silkscreen overlay + molecule pipeline).

Two live wiki pages show it exactly

• ✅ Works (simple board, 6 meshes): https://wiki.adom.inc/adom/controlpanel-mpin-connector POST /convert?molecule=true with STEP + registered silk PNGs -> silkscreen_applied: true, both sides, anchored, 196 KB. Silk (SIDE A, RUD+/-, SDA, pad outlines) is perfectly registered.
• ❌ Fails (complex board, ~174 meshes): https://wiki.adom.inc/adom/bq25792-charger Same call -> silkscreen subprocess times out at 60s, and the killed process leaves out.glb truncated, so unit-normalize, gold, compress, and provenance then all fail with "not a GLB" / "Unexpected end of JSON input". silkscreen_applied: false. (The silk you see on that page is a local hack I had to apply on the optimized GLB as a fallback; it is slightly mis-registered because the raw board bbox included an overhanging connector. Not the service's fault - just proof of what we lose without the in-pipeline bake.)

Root cause

apply_silkscreen runs on out.glb = the raw OCCT tessellation (BQ board: ~16 MB / 174 meshes / 226k verts, pre-join). pygltflib parsing that + the per-node top-face search blows the 60s budget. PNG size is NOT the cause (retried at 15 KB / 793x415, still timed out).

Proof it's the stage, not the code: I ran your exact apply_silkscreen(glb, top, bot) unchanged on the post-optimize GLB (465 KB, 20 meshes) -> completed in 0.3 s, applied: true. Your algorithm is correct.

Fix (two parts)

1. Run the silkscreen overlay AFTER optimize.mjs (on the small joined GLB, not the raw tessellation). ~0.3 s instead of >60 s, scales to any board.
2. Make each post-step copy-in/copy-out (write to a temp, swap on success) so a timeout/crash in one step (silkscreen) can't corrupt the artifact and take down normalize/gold/compress/provenance.

Nice-to-have: bump the 60s subprocess timeout, but (1) makes it moot. I have the failing job ids + the registered silk PNGs if useful.