Federico Jaramillo Martinez
531ccf7b2a
The global provider bootstrap froze all three ModelRuntime mutation methods after startup, so a provider extension that fetched an updated model catalog had that work silently discarded. registerProvider is now applied when the provider ID is already in the frozen baseline and the incoming config equals the recorded baseline in every field except `models`. Refreshing extensions re-send a complete provider config rather than a models-only delta, so the test is "equal except models", not "contains only models". Everything else stays a logged no-op: unknown provider IDs, any change to name/baseUrl/apiKey/api/streamSimple/headers/authHeader/oauth/ refreshModels, native registration, and unregistration. Function-valued fields compare by reference and so always read as a mismatch, which is the intended conservative direction. An accepted update rebases the stored baseline from Pi's merged record, so repeat refreshes work and an unchanged replay is correctly ignored rather than re-applied on every session start. The accept path stays synchronous and never awaits or networks; Pi's own trailing fire-and-forget local refresh is untouched.
803 B
@jmfederico/pi-web
| @jmfederico/pi-web |
|---|
| patch |
Let an already-known provider extension refresh its own model list after daemon startup. Previously every provider registration made after the global bootstrap was ignored, so a provider that fetched an updated model catalog on session start never had those models appear. A registration is now applied when it matches the provider's recorded startup configuration in every respect except the model list; anything else — a new provider, a changed provider base URL, API key, API type, headers, or auth surface, a native provider registration, or an unregistration — is still ignored to keep project-level provider configuration from leaking between workspaces. Documented the refreshed policy under Pi extension provider baseline in the configuration reference.