Fix native deploy readiness: deploy.apply returned a name status lookup couldn't find#87
Open
rjckkkkk wants to merge 1 commit into
Open
Fix native deploy readiness: deploy.apply returned a name status lookup couldn't find#87rjckkkkk wants to merge 1 commit into
rjckkkkk wants to merge 1 commit into
Conversation
…detected deploy.apply registered the native deployment under req.Name (== modelName) but returned the sanitized pod name (model+engine) as "name". The run/onboarding readiness poller and the UI then queried deploy.status by that sanitized name, which the native runtime never registered → status was never found → the deploy appeared stuck and timed out "not ready within 1m" even though the engine was already serving. Return req.Name (the name the runtime actually keyed the deployment under), matching the reuse path and deploy.list/undeploy. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
rjckkkkk
added a commit
that referenced
this pull request
Jun 12, 2026
) New version-stamped build aima-windows-amd64-v0.5-dev-amd-strix-halo-20260612.exe (source commit fa35aa4) on top of the HIP-engine build. Adds, vs the 20260610 exe: #87 native deploy readiness uses the real runtime name (no false "not ready") #88 deploy launcher hidden (no cmd.exe console popup) via VBS launcher #89 Qwen2.5-VL-3B-Instruct catalog knowledge (vlm + aliases + verified perf) #90 zero-config vision: llama.cpp --mmproj auto-wired for VL gguf models #91 openclaw sync preflight-probes :6188 and warns loudly when unreachable serve.bat now points at the 20260612 exe; older builds kept for rollback. README build table + fixes list + OpenClaw data-plane guidance updated. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
On Windows, deploying a model from the UI / onboarding (or
aima run) showed "deployment started but not ready within 1m0s" even though the engine was actually serving fine — the model was reachable on its port the whole time.Root cause:
deploy.applyregisters the native deployment underreq.Name(== the model name — that's whatdeploy.list/undeployuse), but its result returned the sanitized pod name (SanitizePodName(model+"-"+engine), e.g.qwen2-5-vl-3b-instruct-q4-k-m-llamacpp) as"name". The run/onboarding readiness poller (deployRunCore.waitForDeployment) and the UI then polleddeploy.statusby that sanitized name, which the native runtime never registered → status was neverready→ the loop ran to the timeout. The reuse path already returned the runtime name, so the two paths were inconsistent.Fix
Return
req.Name(the name the runtime actually keyed the deployment under) from the non-reuse path ofdeploy.apply, matching the reuse path anddeploy.list/undeploy. One-field change incmd/aima/tooldeps_deploy.go.Verified on the AMD Strix Halo (Win11) rig
aima run Qwen2.5-VL-3B-Instruct-Q4_K_M→ "Ready!" in ~27 s (Endpoint http://127.0.0.1:8080, runtime native). Before the fix the identical command timed out at 60 s with "not ready within 1m" while the model was serving the whole time. Affects every native deploy via the UI/onboarding readiness path; K3S was unaffected (it keys by the sanitized pod name).🤖 Generated with Claude Code