ValueError: 10873 is not in list when compiling HAR with 5th LoRA adapter (DFC 5.2.0)

Environment: DFC 5.2.0, HAR: qwen2_1.5b_instruct.q.har (SDK version 5.1.0.dev0), A100 GPU

After loading a custom LoRA adapter via load_lora_weights() onto the Qwen2-1.5B HAR (which already contains 4 pre-existing adapters), compile() fails with ValueError: 10873 is not in list in precision_splitter.py:122.

The root cause appears to be that load_lora_weights() injects new lora_add nodes but doesn’t register their indices in PrecisionSplitterLayer._output_indices. When we monkey-patched _get_output_shape to provide fallback shapes, the Python serialization succeeds but the C++ compiler then fails with Assertion 'real_index != m_successors_indices.end()' — suggesting the same missing connectivity exists in the protobuf.

The DFC docs indicate optimize() should be called after each load_lora_weights(), but the HAR is in quantized_model state which blocks optimize(). Is there a supported path for adding LoRA adapters to an already-quantized HAR, or must the optimize step happen (which is blocked by the existing state)?

I’ve attempted eight rounds of protobuf surgery, but it’s gotten increasingly fragile, and I’m fairly certain that I’m introducing inference bugs by trying this approach.

I don’t really have a path forward, and I’ve spent a few days on this.