ZacharyZhang-NY
7ec25bf629
The report row contradicted itself. The reason came from the attachment record while path, adapter_id, base_model, origin and cartridge_id came from whatever resolution preferred right now. Reproduced without any stubbing: a live model holds adapter X, training writes a newer adapter Y, and the endpoint then answers state=loaded adapter_id=adapter-Y while explaining "attached to the live model from .../x-attached". A JSON consumer reads the identity columns as the loaded adapter and gets the wrong one. The same root cause had a second symptom. Attachments were keyed by kind with last-writer-wins, so with two live runtimes one unload made the row claim "that model is gone" while the other runtime's model was still alive holding its adapter. LoadRecord now carries the AdapterSource it came from, so a row built from a record has exactly one identity, and the registry is a list of attachments each holding its own weak reference: loaded means some live model still holds an adapter, and when more than one does the reason names the other. clear_loads had no production caller once unload stopped erasing the process record, so it is gone rather than kept as a test-only entry point. Two tests pin both symptoms, and both were mutation-checked: restoring the identity to the resolved source fails the first, and letting live_attachments ignore liveness fails the second and the unload test. pytest -q: 227 passed. ruff clean. mypy cold cache on the three touched source files: 2 errors, byte-identical to the same command on a stashed HEAD tree, net zero. pyright: 2 errors, both the known qwen_vl_utils tuple artifact, unchanged from HEAD.
Ely-Eye Backend
FastAPI, ingestion, memory, retrieval, runtime, verifier, evaluation, and training services for Ely-Eye.