Headless CLI silently falls back to filament_max_volumetric_speed=2 when the inherits chain doesn't resolve, inflating reported print time ~3x

[jwalker279-cmd]

Headless CLI silently falls back to filament_max_volumetric_speed = 2 when the filament inherits chain doesn't resolve, inflating reported print time ~3×

Version: QIDIStudio 02.07.02.10 (Win64), headless CLI.
Mode: headless slicing with --load-filaments pointed at a shipped "leaf" filament profile (one that inherits from a base profile via "inherits").

Summary

Shipped filament profile JSON leaves most numeric fields (including filament_max_volumetric_speed) undefined at the leaf level — they only exist on the base profile it inherits from. The GUI resolves the inherits chain and applies the base value (typically ~14–21 mm³/s depending on material/nozzle). The headless CLI does not reliably resolve this chain: when it fails, filament_max_volumetric_speed silently falls back to a compiled default of 2 mm³/s, which is far below what the part actually needs. Every extrusion move is then computed against that tiny ceiling, and reported print time balloons — one real case: a print that takes ~12h33m was reported as 35h.

There is no error or warning — result.json says "Success." and the number just looks absurd if you happen to know the part.

Repro

1. Slice a 3MF headlessly using a shipped filament leaf profile as-is via --load-filaments.
2. Check the gcode header for ; filament_max_volumetric_speed = .
3. Compare against the same slice with the inherits chain manually flattened (leaf profile copied with the base's numeric fields, especially filament_max_volumetric_speed, inlined).

Expected: headless slicing resolves inherits the same way the GUI does, and reports the real ceiling.
Actual: it can silently use 2, and total print time is inflated by roughly the ratio of real_speed / 2.

Workaround (in use here)

Before slicing headlessly, leaf-patch a copy of the filament JSON with the resolved numeric fields set directly (filament_max_volumetric_speed, temps, etc.) rather than relying on inherits to resolve. Always verify ; filament_max_volumetric_speed = <expected> in the gcode header before trusting a headless time estimate.

Suggested fix

Resolve the inherits chain for --load-filaments/--load-settings inputs the same way the GUI's profile loader does, or fail the slice with a clear error if a required field can't be resolved — rather than silently substituting a compiled default that's off by an order of magnitude from any real material.