the bytes reached the pod, the entry did not (v0.3.93)
Measured on a live pod. The pool gate from v0.3.91 worked —
[lora] no adapters yet, but this engine serves a pool — starting with LoRA
enabled so one can be added without a reload
[vllm] launching: … --enable-lora --max-lora…
— and the adapter was still dropped:
pod seeded expecting : sha256:2e820c… (the local adapter directory)
re-registered as : sha256:b8eac366… (an uploaded blob)
orchestrator pushed : b8eac366… ✓ 159 MB
The bytes arrived. The pod's CATALOGUE did not. It was seeded at boot with the
first id, /v1/loras/register repointed the entry at the second, and nothing
told the pod — so its engine looked for an id nobody holds, dropped the
adapter, and served the base under its name. (The bundle hash is deterministic;
the two ids differ because the adapter genuinely changed, not because hashing
is unstable.)
Two keys missing a version, the same shape as every other bug in this area:
* _ensure_adapters sent the BYTES only. It sends bytes and entry now.
* teach_model keyed "already taught" on (pod, model), so a re-register could
never reach a pod it had spoken to once. Keyed on the adapter's source.
/v1/loras listed only the TRAINING registry, so an adapter that arrived by
upload+register was invisible there — a successful registration looked exactly
like a failed one, which is how this was found. It lists both now, tagged
`trained` or `registered`, with the adapter id, base and pool.
Co-Authored-By:
Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HXRMe9ZPUQCCCtBai9uqt3
Showing
Please
register
or
sign in
to comment