mirror of
https://github.com/QwenLM/qwen-code.git
synced 2026-11-07 06:19:43 -10:00
Shaojin Wen
ef4c13283f
* fix(managed-agent): pass the pool Harness the Broker pair serve removes The Kubernetes launcher handed `qwen serve` the Broker URL and token as QWEN_HOSTED_HARNESS_BROKER_URL/_TOKEN. runQwenServe read that pair as a fallback but never removed it from process.env, so the token stayed in the Harness environment for the life of the process, and children started with that environment inherited it. The systemd Harness passes QWEN_MANAGED_RUNTIME_BROKER_URL/_TOKEN instead, which the serve handler reads and deletes at startup. - The launcher and harness-pool.yaml use QWEN_MANAGED_RUNTIME_BROKER_URL and _TOKEN, so both deployments share one pair and one removal. - Drop the QWEN_HOSTED_HARNESS_BROKER_* fallback and its process.env guard allowance. - Test the launcher's child environment against the names serve deletes, the manifest against every variable the launcher reads, and the handler's removal of the pair. * fix(managed-agent): name a missing pool Broker URL - The launcher reports a missing QWEN_MANAGED_RUNTIME_BROKER_URL as "The pool requires a Broker URL." rather than the generic configuration error, so a manifest that still sets the old name shows up in the Pod log. - The handler test records the Broker pair when the runtime starts, since the runtime snapshots process.env for every process it starts. Checking after the handler returned could not tell a delete before runQwenServe from one after it. - The Kubernetes README no longer says the systemd Harness uses these names; on main it still passes the pair as command-line flags. * fix(managed-agent): name the pool Broker URL variable in launcher errors The Broker URL variable is the input this change renamed, so each launcher error about it now names QWEN_MANAGED_RUNTIME_BROKER_URL, and a URL that does not parse gets its own message instead of the generic configuration error. Messages still never include the value. The Kubernetes README now limits the startup-scrub statement to the pool's `--profile hosted-harness` launch, which always reaches the full serve handler; the serve fast path does not read the pair. * fix(managed-agent): name the Broker URL rename and refuse a path in the pool launcher The v0.26.1 manifest sets the Broker URL as QWEN_HOSTED_HARNESS_BROKER_URL, which nothing reads any more, so a Deployment created from it stops at the launcher. The launcher now names the rename when only the old name is set, and both Kubernetes READMEs say to rename it before rolling out a later image. qwen serve takes an origin only, so a Broker URL with a path passed the launcher and then stopped serve at boot without naming the variable. The launcher now refuses it with its own message. The READMEs also say that the environment qwen serve started with stays readable in /proc/<pid>/environ to processes of the same user in the container, so removing the pair stops inheritance, not that exposure. * docs(managed-agent): rename the pool's Broker URL in the same apply as the image Renaming the Deployment variable on its own rolls Pods that still run the v0.26.1 image, whose launcher reads only the old name and exits with the generic configuration message, so the rollout stalls without naming the rename; an image rollback produces the same mix. Both Kubernetes READMEs now apply the rename and the new image digest together, describe the stalled rollout, and say that a rollback restores the old name with the old image. The launcher test also pins the full qwen serve argv, including --profile hosted-harness, and checks the credential, query and fragment arms of the HTTPS Broker URL guard, not only the protocol. * test(managed-agent): say why the pool launcher test pins the serve profile serve.ts removes the Broker pair whatever the profile. The profile is what lets validateHostedHarnessProfile accept the pair, and a launch without it exits instead of starting a default daemon, so the comment over the argv pin now says that.