Context
Follow-up to PR #1704 (merged), per @johntmyers's request.
The new route-resolution tests added in PR #1704 (upsert_cluster_route_* in crates/openshell-server/src/inference.rs) insert Provider records directly via store.put_message. That covers the routing logic but bypasses the public CLI path operators actually use:
openshell provider create --type aws-bedrock --credential ... --config BEDROCK_BASE_URL=...
If a built-in profile (aws-bedrock, deepinfra, nvidia, openai, anthropic, google-vertex-ai) drifts from what the gRPC provider create handler accepts — required vs. optional credential validation, discovery behaviour, defaulting — the existing tests won't catch it.
Scope
Add coverage that goes through openshell_server::grpc::provider::ProviderService::create_provider (or the equivalent public entrypoint) for each built-in profile:
- Positive create path: the documented
provider create --type <profile> ... command shape produces a stored Provider record matching what resolve_provider_route expects.
- Cluster route end-to-end: chain
create_provider → upsert_cluster_inference_route (with verify: false for protocols not yet supported by the validation probe — currently aws_bedrock_invoke, but this list is short).
- Negative paths: for each profile, the gRPC
create_provider rejects malformed inputs (empty credential map where required, unknown profile type, etc.) with the same error shape the CLI surfaces.
Why this matters
Documentation in docs/sandboxes/manage-providers.mdx and docs/sandboxes/inference-routing.mdx shows specific provider create commands. Today nothing pins those down to behaviour. A test layer one level up from the route-resolution unit tests would catch docs/profile drift before users do.
Related
Context
Follow-up to PR #1704 (merged), per @johntmyers's request.
The new route-resolution tests added in PR #1704 (
upsert_cluster_route_*incrates/openshell-server/src/inference.rs) insertProviderrecords directly viastore.put_message. That covers the routing logic but bypasses the public CLI path operators actually use:If a built-in profile (
aws-bedrock,deepinfra,nvidia,openai,anthropic,google-vertex-ai) drifts from what the gRPCprovider createhandler accepts — required vs. optional credential validation, discovery behaviour, defaulting — the existing tests won't catch it.Scope
Add coverage that goes through
openshell_server::grpc::provider::ProviderService::create_provider(or the equivalent public entrypoint) for each built-in profile:provider create --type <profile> ...command shape produces a storedProviderrecord matching whatresolve_provider_routeexpects.create_provider→upsert_cluster_inference_route(withverify: falsefor protocols not yet supported by the validation probe — currentlyaws_bedrock_invoke, but this list is short).create_providerrejects malformed inputs (empty credential map where required, unknown profile type, etc.) with the same error shape the CLI surfaces.Why this matters
Documentation in
docs/sandboxes/manage-providers.mdxanddocs/sandboxes/inference-routing.mdxshows specificprovider createcommands. Today nothing pins those down to behaviour. A test layer one level up from the route-resolution unit tests would catch docs/profile drift before users do.Related