Re: [I] Model catalog metadata is stale, and clients resolve it instead of Runtime Host [maka]

["Astro-Han (via GitHub)" <gi...@apache.org>]

Astro-Han commented on issue #4398:
URL: https://github.com/apache/maka/issues/4398#issuecomment-5497957459

   Closing — all three proposed changes are on `main`:
   
   - **Host is the sole catalog authority** — #4411. Desktop, TUI and CLI read the Host's projection instead of their own tables.
   - **Runtime refresh** — #4467. The Host fetches models.dev once at startup and installs a whole projection, reaching clients as `connection.catalog.changed`.
   - **Scheduled snapshot upkeep** — #4460. A weekly refresh opens a draft pull request, and a snapshot-versus-upstream drift check now exists — the absence of one is why the original staleness went unnoticed.
   
   Three of the four simplifications landed with them, verified against `main`:
   
   - `makeMissingDefaultEntry` / `makeMissingUserChoiceEntry` are gone; only comments still carry the names.
   - `PROVIDER_DEFAULTS` is gone; `provider-registry.ts:1626` exports `PROVIDER_REGISTRY` as the one name.
   - `ModelCatalogEntry.thinkingLevels` (`model-catalog.ts:81`) merged the two projections, and its comment records why they had drifted.
   
   **One item stays open, exactly as this issue predicted it would.** The "Omissions to cover" section noted that raw-level survival at the storage read boundary "has no coupling to the models.dev runtime refresh and is not part of that change", and it isn't. On `main` today, `connection-catalog-document.ts:130` maps every maintained row through `decodeCanonicalConnectionCatalogEntry`, which reaches `decodeProviderType` (`connection-catalog-codec.ts:155`); that throws for a provider the running build does not know, so one unregistered row fails the whole catalog read with `invalid_document` and the Host loses every connection rather than that one. The seam is the `isRetiredGeminiCliConnection` filter directly above it at `:123`, which already survives a row before the strict decode runs.
   
   Rather than hold this issue open as a container for one unrelated item, I'm tracking that separately.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org