Summary
The V2 admin Connections card can test a model connection before saving it. The new Embeddings and Image generation sections cannot — there is no equivalent affordance, so an administrator configuring an embedding endpoint in V2 has no way to check it works short of indexing a document and watching for failure.
Why it was left out
The obvious fix — reuse the classic page's test button — does not transfer cleanly.
Connection testing in the classic admin page is not a set of per-capability routes. It is a single dispatching route, POST /api/admin/settings/test_connection, discriminated by a test_type field. Its payload is assembled by admin_settings.js from the current, unsaved form values, which necessarily includes the raw secret as typed into the form.
That is exactly the shape phase 3's new password field type is designed to avoid. It is a write-only control: a stored credential never occupies a form control, and a blank input means "keep what is stored" rather than travelling with the request. Wiring V2 into the existing test route would have meant reconstructing a payload with the credential in it, reintroducing the property the control was added to remove.
Rather than build a second payload shape around a live secret, phase 3 left testing on the classic page and flagged it.
What good would look like
A test endpoint that takes a reference to stored configuration rather than a bundle of form values — resolving the secret server-side the way resolve_admin_settings_secret_value already does for saves — so the credential never leaves the server. That would serve V2 for embeddings, image generation and any future capability, and would let the classic page stop shipping secrets in a test payload too.
An interim option is to test only already-saved configuration, which is the common case: configure, save, then test.
Worth noting the Connections card does not have this problem, because /api/models/test-connection accepts an endpoint payload and phase 1's editor holds an unsaved connection in memory by design. The asymmetry is between settings-document capabilities and connection resources, not an oversight in one of them.
Provenance
Found by the phase 3 session while implementing the Embeddings and Image generation sections. The brief assumed POST /api/admin/test-embedding-connection and /api/admin/test-image-connection existed; they do not. Recorded so the gap is a decision rather than an omission.
Related
Summary
The V2 admin Connections card can test a model connection before saving it. The new Embeddings and Image generation sections cannot — there is no equivalent affordance, so an administrator configuring an embedding endpoint in V2 has no way to check it works short of indexing a document and watching for failure.
Why it was left out
The obvious fix — reuse the classic page's test button — does not transfer cleanly.
Connection testing in the classic admin page is not a set of per-capability routes. It is a single dispatching route,
POST /api/admin/settings/test_connection, discriminated by atest_typefield. Its payload is assembled byadmin_settings.jsfrom the current, unsaved form values, which necessarily includes the raw secret as typed into the form.That is exactly the shape phase 3's new
passwordfield type is designed to avoid. It is a write-only control: a stored credential never occupies a form control, and a blank input means "keep what is stored" rather than travelling with the request. Wiring V2 into the existing test route would have meant reconstructing a payload with the credential in it, reintroducing the property the control was added to remove.Rather than build a second payload shape around a live secret, phase 3 left testing on the classic page and flagged it.
What good would look like
A test endpoint that takes a reference to stored configuration rather than a bundle of form values — resolving the secret server-side the way
resolve_admin_settings_secret_valuealready does for saves — so the credential never leaves the server. That would serve V2 for embeddings, image generation and any future capability, and would let the classic page stop shipping secrets in a test payload too.An interim option is to test only already-saved configuration, which is the common case: configure, save, then test.
Worth noting the Connections card does not have this problem, because
/api/models/test-connectionaccepts an endpoint payload and phase 1's editor holds an unsaved connection in memory by design. The asymmetry is between settings-document capabilities and connection resources, not an oversight in one of them.Provenance
Found by the phase 3 session while implementing the Embeddings and Image generation sections. The brief assumed
POST /api/admin/test-embedding-connectionand/api/admin/test-image-connectionexisted; they do not. Recorded so the gap is a decision rather than an omission.Related
passwordfield typeenable_multi_agent_orchestrationas an editable toggle in AI Models → Connections #1420, Search summaries, block-revision assist and workflow runners always use the classic GPT endpoint, which V2 cannot configure #1427 — other findings deliberately kept out of the AI Models stack