Summary
POST /creator/knowledge-stores reports 409 "Knowledge Store name already taken in this organization" for any insert failure, including causes that have nothing to do with names. The message sends whoever hits it looking for a name conflict that does not exist.
How it surfaced
Every create attempt returned the 409 — including names carrying a unix timestamp, so a genuine collision was impossible — while lamb knowledge-store list returned an empty list and the KB server reported zero collections.
The actual cause was a missing table: LAMB_knowledge_stores had never been created on that database, because of the migration-number collision filed separately. The insert failed, and the handler translated that into a name conflict.
Where
backend/creator_interface/knowledge_store_router.py — the create handler:
inserted = _db.create_knowledge_store(...)
if not inserted:
raise HTTPException(
status_code=409,
detail="Knowledge Store name already taken in this organization.",
)Any falsy return becomes "name already taken": missing table, constraint violation, database error, permission problem. library_router.py has the same shape for libraries and presumably the same behaviour.
Why it matters beyond the immediate bug
A wrong error message is worse than a generic one, because it actively redirects the investigation. Here it turned a schema problem into what looked like a trivial naming problem, and the real cause — a table that did not exist — was two layers down.
Suggested fix
Distinguish the cases at the source. Have create_knowledge_store signal why it failed rather than returning a bare falsy value — either by letting the database exception propagate to a handler that maps constraint violations to 409 and everything else to 500, or by returning a result that carries the reason. A unique-constraint violation is a 409; anything else is a 500 with the underlying error logged.
Worth applying the same treatment to the library create path.
Summary
POST /creator/knowledge-storesreports 409 "Knowledge Store name already taken in this organization" for any insert failure, including causes that have nothing to do with names. The message sends whoever hits it looking for a name conflict that does not exist.How it surfaced
Every create attempt returned the 409 — including names carrying a unix timestamp, so a genuine collision was impossible — while
lamb knowledge-store listreturned an empty list and the KB server reported zero collections.The actual cause was a missing table:
LAMB_knowledge_storeshad never been created on that database, because of the migration-number collision filed separately. The insert failed, and the handler translated that into a name conflict.Where
backend/creator_interface/knowledge_store_router.py— the create handler:Any falsy return becomes "name already taken": missing table, constraint violation, database error, permission problem.
library_router.pyhas the same shape for libraries and presumably the same behaviour.Why it matters beyond the immediate bug
A wrong error message is worse than a generic one, because it actively redirects the investigation. Here it turned a schema problem into what looked like a trivial naming problem, and the real cause — a table that did not exist — was two layers down.
Suggested fix
Distinguish the cases at the source. Have
create_knowledge_storesignal why it failed rather than returning a bare falsy value — either by letting the database exception propagate to a handler that maps constraint violations to 409 and everything else to 500, or by returning a result that carries the reason. A unique-constraint violation is a 409; anything else is a 500 with the underlying error logged.Worth applying the same treatment to the library create path.