Problem
Adding a custom relay asks for a model id as free text. Maka fetches the endpoint's catalog immediately after the connection is created, so the value the user typed is usually replaced seconds later — they were asked to guess something the app was about to find out.
The ordering is what forces it: fetchModels (bridge-contract.d.ts:802) takes a connection slug, so discovery cannot run until the connection exists. The form therefore has nothing to offer while the user is filling it in, and free text is the only honest control for a value nobody knows yet.
The immediate harm is addressed separately — the field is no longer required, and a failed fetch is now reported instead of swallowed. What remains is that the user still cannot see the catalog at the moment they are choosing from it.
What this needs
A probe: given a base URL and credentials, list the models that endpoint serves, without persisting a connection.
That is a new operation, not a new caller of an existing one. Sketch of the surface it would cross:
- a Runtime Host operation that performs discovery against supplied connection material rather than a stored connection
- the preload/IPC surface to reach it
- a "fetch models" action in the add form, turning the model field into a picker once it returns
RUNTIME_HOST_COMPATIBILITY_EPOCH — a new wire operation is a decode change in the new-Client-against-old-Host direction
Decisions worth settling before implementation
- Where the probe runs. Discovery from the Host keeps credentials off the renderer, matching how
fetchModels already works. It also means the probe inherits the Host's network path, which is the one that matters — a relay reachable from the renderer but not the Host would otherwise pass the probe and fail in use.
- What it may keep. Nothing, ideally: a probe that writes no connection and caches no credential has no cleanup story and no half-created state to reconcile. That constrains the operation shape.
- What a failed probe means. It must not block creation. An endpoint that serves no catalog is a supported configuration — that is exactly when a hand-typed model id is the right answer.
Not in scope
Changing how discovery works for connections that already exist. fetchModels and the "update models" action in the connection detail are unaffected.
Refs #3443
Problem
Adding a custom relay asks for a model id as free text. Maka fetches the endpoint's catalog immediately after the connection is created, so the value the user typed is usually replaced seconds later — they were asked to guess something the app was about to find out.
The ordering is what forces it:
fetchModels(bridge-contract.d.ts:802) takes a connection slug, so discovery cannot run until the connection exists. The form therefore has nothing to offer while the user is filling it in, and free text is the only honest control for a value nobody knows yet.The immediate harm is addressed separately — the field is no longer required, and a failed fetch is now reported instead of swallowed. What remains is that the user still cannot see the catalog at the moment they are choosing from it.
What this needs
A probe: given a base URL and credentials, list the models that endpoint serves, without persisting a connection.
That is a new operation, not a new caller of an existing one. Sketch of the surface it would cross:
RUNTIME_HOST_COMPATIBILITY_EPOCH— a new wire operation is a decode change in the new-Client-against-old-Host directionDecisions worth settling before implementation
fetchModelsalready works. It also means the probe inherits the Host's network path, which is the one that matters — a relay reachable from the renderer but not the Host would otherwise pass the probe and fail in use.Not in scope
Changing how discovery works for connections that already exist.
fetchModelsand the "update models" action in the connection detail are unaffected.Refs #3443