Two gaps a review surfaced.
Moving a record from one catalog provider to another changed neither field the
check looked at, so an unchanged credential started being offered to a
different vendor, under a different auth header, with nothing asking whether it
was accepted there.
And each host lookup built its own eight-second budget from a background
context, so a slow resolver could spend one before the request spent another,
and a caller that gave up was still waiting. Bedrock made that three: it now
checks its runtime host as well. One deadline is taken at the top of Fetch and
carried through both lookups and the request.
The create description also had the exemption backwards, reading as though an
upstream the check cannot reach is stored unverified. Unreachable blocks; only
what cannot be checked at all is exempt.
Editing a provider's upstream URL meant retyping its API key. The key is the
one field the API never returns, so there was nothing to retype from, and the
dashboard had to demand it because a provider_id request resolved the upstream
from the stored row — listing the old endpoint while the form showed the new
one.
The request now reads as a partial edit of the record it names, the same way
PUT on a provider already does: an upstream in the body overrides the stored
one, an omitted upstream keeps it. The credential and the catalog entry still
come from the record only, so a caller cannot aim a stored key at a vendor of
their choosing.
Pressing "Load models from provider" against a key the vendor refuses answered
"internal server error". Every outcome on that path is the operator's own key
or upstream, so a 500 was wrong twice over: it told them the server broke, and
it named nothing they could act on.
The failures are already typed and already have sentences written for them —
the save-time check translates the same set. Discovery now runs them through
the same classifier, so the button reports a refused credential or an
unreachable url in the words the form uses elsewhere.
ErrNoDiscovery and ErrInvalidRequest pass through untouched. The handler maps
both already, and a provider with no listing endpoint is a fact about the
catalog entry rather than a failure — the caller falls back to the catalog's
own models instead of showing an error at all.
The dial-time guard reported every non-public address as ErrPrivateHost, which
the credential check reads as "this upstream cannot be reached from here, so
save it unchecked". checkPublicHost has already cleared the target by the time
anything is dialled, so an address refused at the socket is never the
operator's upstream — it is a rebinding attempt, or an HTTP proxy the
management server egresses through. A deployment behind such a proxy would
install this feature and have it silently do nothing on every provider.
It now reports an ordinary failure, which classifies as unreachable and blocks.
Only the resolve-stage check still means "cannot be checked", and that one
knows it is looking at the operator's own host.
This is also why the three fixtures below passed locally and failed in CI: a
sandbox that egresses through a loopback proxy skipped the check entirely,
while CI reached the real api.openai.com and had the dummy key refused. They
want a provider row rather than a working vendor, so they move to a private
address and no longer depend on where a hostname resolves or whether the runner
has egress.
The provider form accepted anything and found out later. A typo in the
upstream, a key pasted a character short, an AWS access key in a field that
wants a Bedrock API key — all saved cleanly, then surfaced minutes later as a
failed request or an empty model picker, with nothing pointing back at the
record that caused it.
CreateProvider now spends the credential once against the vendor's own model
listing, and UpdateProvider does the same when the upstream or the key
changed — only then, so renames, model rows and price edits neither wait on a
vendor nor fail because one is having a bad day. Both run before the store
write, so a rejected rotation leaves the working key exactly where it was.
The check reuses the discovery Fetch rather than a lighter status probe. It
exercises the path the model picker will take, so a URL answering 200 with a
login page fails here instead of passing a status check and producing an empty
picker later.
Failures that mean "we cannot ask" are not failures: a gateway with no listing
endpoint, a Bedrock record behind a proxy where no control-plane host can be
derived, and a self-hosted endpoint on a private network that the proxy
reaches through the tunnel but management cannot. None of those are evidence
the record is wrong, and refusing them would make this a lockout.
Discovery failures are typed for it. The message an operator sees carries no
status code and never echoes their URL — WriteError lowercases it, and paths
are case-sensitive, so an echoed URL would come back altered and describe
something they did not type. The vendor's status is logged instead.
mlsmaycon