A search-tool name containing '/' stores a row no route can address

[dpoulopoulos]

POST /api/v1/search-tools accepts any non-empty name:

name: str = Field(min_length=1, description="Name callers pass as 'search_tool_name' or in /api/v1/search/{tool}.")

A name containing / stores fine and then cannot be addressed. Neither /api/v1/search-tools/team%2Fbrave nor the bare /api/v1/search-tools/team/brave matches a /{name} route: Starlette's path parameters do not span a segment boundary, and the encoded form is decoded after routing, so it 404s too. Confirmed against a minimal app, both spellings.

The result is a row that can be created but never read, updated or deleted through the API. It also cannot be dispatched to, since /api/v1/search/{tool} has the same shape.

Why this is filed rather than fixed on #1211

The same gap was raised against the new guardrail store on #1211 and fixed there: #1211 (comment)

CreateGuardrailCredentialRequest.name now carries pattern=r"^[^/]+$". The search-tool store is a different resource on a branch that does not touch it, and the fix moves docs/public/openapi.json, the Postman collection and web/src/client/schema.ts, so it belongs in its own change rather than widening a feature branch.

Scope

• pattern=r"^[^/]+$" on the search-tool create request's name, matching what the guardrail store now does.
• Check whether provider_credentials has the same shape; its instance names are addressed the same way.
• Existing rows are unaffected: nothing can have reached the table through a path, only through this body, so a deployment that already stored one still needs a manual cleanup. Worth a line in the PR description if any are found.
• The four generated artifacts regenerate with it.

[AloysJehwin]

I picked this up to fix and found it already covered on main (at 15aca94), so posting the evidence rather than opening a redundant PR.

POST /api/v1/search-tools does not validate the name in the Pydantic model, but the route calls _validate_entry before anything is stored (src/gateway/api/routes/search_tools.py:332), which delegates to validate_search_tool_entry and turns a ValueError into a 422:

# search_tools.py:196-199
try:
    validate_search_tool_entry(name, entry)
except ValueError as exc:
    raise HTTPException(status_code=status.HTTP_422_UNPROCESSABLE_CONTENT, detail=str(exc)) from None

and that validator rejects the slash (src/gateway/core/config.py:198):

if "/" in name:
    msg = f"search tool name '{name}' must not contain '/' (it is used as a URL path segment)."
    raise ValueError(msg)

Its docstring says this is deliberate: "Module-level rather than a method so the runtime CRUD path (/api/v1/search-tools) can hold a dashboard-written tool to the same rules the config file is held to at startup."

There is also a test asserting exactly this, tests/integration/test_search_tools_api.py:106:

def test_name_used_as_a_path_segment_may_not_contain_a_slash(...):
    resp = _create(client, master_key_header, name="a/b")
    assert resp.status_code == 422
    assert "must not contain '/'" in resp.json()["detail"]

So a row with a / cannot be created through the API, and the "created but unaddressable" outcome does not occur. The response is a 422 with a specific message rather than the model-level 422 a pattern= would give, which reads better anyway.

On the issue's second scope item — whether provider_credentials has the same shape: it is guarded too, and more strictly. _validate_instance (src/gateway/api/routes/providers.py:406) rejects both characters:

if ":" in instance or "/" in instance:
    raise HTTPException(status_code=400, detail="Provider instance name must not contain ':' or '/'.")

I did separately confirm the routing premise, since it is the part worth keeping on record. Against a minimal FastAPI app with a /{name} route:

/api/v1/search-tools/brave         -> 200  {'name': 'brave'}
/api/v1/search-tools/team%2Fbrave  -> 404
/api/v1/search-tools/team/brave    -> 404

Both spellings 404, exactly as described, so the guard is doing real work.

Worth closing unless you want the pattern= on the model as belt-and-braces (it would move openapi.json, the Postman collection and schema.ts for a case the route already refuses). Happy to open that if you'd prefer the constraint visible in the schema.