The catalog-3 public-API release run for qwen35-litert-gpu completes earlier generation cases but times out during C12.guards unload/reload recovery on macOS arm64. The suite records the failure correctly; this issue tracks the runtime/lifecycle investigation, not an assumed upstream cause.
Repro: clean portable bundle from source 89097b704fbfe90718484cd577076e7a5cb7083d, native v0.4.1, LiteRT-LM 0.17.0-5, locked Qwen3.5 0.8B INT8 profile, release selection. Run the normal suite through C12.guards, which unloads the model, checks the public not-ready exception, reloads and requests the hello recovery fixture.
Observed journal: C12.guards ERROR case_timeout after 60,000 ms; subsequent Unicode-generation and second-reload obligations NOT_RUN (prior_timeout); cleanup ERROR Timed-out backend operation has not settled; run_end written. The CLI process remains alive after that journal and was explicitly terminated, with the failure artifacts preserved. Final counts: 14 PASS, 1 history FAIL, 1 ERROR, 5 NOT_RUN; unqualified. LiteRT GPU placement is separately unverified and is not credited as actual GPU inference.
The native stderr near the last reload contains WebGPU serialized-cache initialization followed by DATA_LOSS: Deserialization failed in webgpu/inference_context.cc:187. This is a diagnostic lead, not proof of the root cause. Same-source Gemma LiteRT GPU completes the new guard; Qwen LiteRT CPU also completes it.
Investigate whether cache reuse, reload ordering, native operation settlement or worker teardown causes the hang. Add positive and negative lifecycle regression coverage; verify that the bounded runner can terminate or report an unsettled backend without indefinitely retaining the process. Do not weaken timeout or qualification rules to hide it.
Evidence: #515, followup-20260918/macos-release-qwen35-litert-gpu/{events.jsonl,stderr.log,results.json}. Broader coverage tracker #514.
The catalog-3 public-API release run for
qwen35-litert-gpucompletes earlier generation cases but times out during C12.guards unload/reload recovery on macOS arm64. The suite records the failure correctly; this issue tracks the runtime/lifecycle investigation, not an assumed upstream cause.Repro: clean portable bundle from source
89097b704fbfe90718484cd577076e7a5cb7083d, nativev0.4.1, LiteRT-LM0.17.0-5, locked Qwen3.5 0.8B INT8 profile, release selection. Run the normal suite through C12.guards, which unloads the model, checks the public not-ready exception, reloads and requests the hello recovery fixture.Observed journal: C12.guards ERROR
case_timeoutafter 60,000 ms; subsequent Unicode-generation and second-reload obligations NOT_RUN (prior_timeout); cleanup ERRORTimed-out backend operation has not settled; run_end written. The CLI process remains alive after that journal and was explicitly terminated, with the failure artifacts preserved. Final counts: 14 PASS, 1 history FAIL, 1 ERROR, 5 NOT_RUN; unqualified. LiteRT GPU placement is separately unverified and is not credited as actual GPU inference.The native stderr near the last reload contains WebGPU serialized-cache initialization followed by
DATA_LOSS: Deserialization failedinwebgpu/inference_context.cc:187. This is a diagnostic lead, not proof of the root cause. Same-source Gemma LiteRT GPU completes the new guard; Qwen LiteRT CPU also completes it.Investigate whether cache reuse, reload ordering, native operation settlement or worker teardown causes the hang. Add positive and negative lifecycle regression coverage; verify that the bounded runner can terminate or report an unsettled backend without indefinitely retaining the process. Do not weaken timeout or qualification rules to hide it.
Evidence: #515,
followup-20260918/macos-release-qwen35-litert-gpu/{events.jsonl,stderr.log,results.json}. Broader coverage tracker #514.