fix(daemon): gracefully handle unrecognized custom models without throwing undefined API errors#175
fix(daemon): gracefully handle unrecognized custom models without throwing undefined API errors#175douo wants to merge 1 commit intosteipete:mainfrom
Conversation
…using proxy base url
There was a problem hiding this comment.
Pull request overview
Fixes a daemon crash when a user configures an unrecognized/custom model ID (especially alongside a custom Base URL) by ensuring model resolution never returns an “incomplete” model object that’s missing required fields like api.
Changes:
- Avoid passing an undefined model result into
overrideModelBaseUrlby storing thegetModel(...)result in a local variable. - Explicitly throw when
getModel(...)returns no model so the existing fallback logic reliably generates a valid synthetic model.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| const model = getModel(provider as never, modelId as never); | ||
| if (!model) throw new Error(`Model not found: ${provider}/${modelId}`); | ||
| return overrideModelBaseUrl( | ||
| getModel(provider as never, modelId as never) as Model<Api>, | ||
| model as Model<Api>, |
There was a problem hiding this comment.
The new branch where getModel(...) returns a falsy value and we intentionally throw to enter the fallback path isn’t covered by tests. Please add a Vitest case (likely in tests/daemon.agent.test.ts, which already mocks getModel) that simulates getModel returning undefined for an unknown model ID while a custom base URL is configured, and assert completeAgentResponse still calls completeSimple with a model that has a defined api (and uses the overridden baseUrl). This guards against regressions of the original api: undefined crash.
There was a problem hiding this comment.
@copilot open a new pull request to apply changes based on this feedback
Description:
What does this PR do?
This PR fixes a bug in the daemon where chat requests would crash with a
No API provider registered for api: undefinederror if the user configured a custom, unrecognized model ID (e.g.openai/Qwen3-Coder-480B-A35B-Instruct) alongside a custom Base URL.Why did this happen?
When
@mariozechner/pi-ai's getModel function receives an unknown model ID, it safely returnsundefined. Previously, the resolveModelWithFallback function in src/daemon/agent-model.ts was passing thisundefinedobject directly to overrideModelBaseUrl. When abaseUrlwas present, the destructured object{ ...model, baseUrl }yielded an object that literally consisted of just{ baseUrl: "..." }. ThestreamSimpleengine then choked during execution because the critical.apiproperty on this mock model object was entirely missing (undefined).How was it fixed?
Added an explicit check (
if (!model) throw new Error(...)) immediately after fetching the model from the PI-AI registry. By voluntarily throwing an error when the model is undefined, we correctly redirect the execution flow to the existing designatedcatchblock for fallback logic. This catch block safely generates a comprehensive synthetic model containing the necessaryapi: "openai-completions"identifier, allowing conversations using local/custom endpoints to resume working flawlessly.