Overview
The issue arises from improper scoping of unique slug validation between shared and private brains.
Currently, when a user tries to create a new brain in private mode, the system incorrectly flags it as already existing if any other brain even in a shared workspace or owned by another user has the same slug.
This happens due to missing contextual checks (no differentiation between workspace/user scope in uniqueness validation).
It affects usability and collaboration by preventing legitimate private brain creation.
Affected Endpoint and Files
List the exact API routes, files, and functions involved.
- Endpoint(s):
POST /api/brains (Brain creation)
PATCH /api/brains/:id (Brain update)
- Route file:
server/routes/brain.routes.ts
- Controller:
server/controllers/brain.controller.ts
- Service/DAO:
path/to/service.js
Steps to Reproduce
1. User A creates a shared brain named "Test Brain 1" (but does not share it with User B).
2. User B attempts to create a new brain (private or shared) named "Test Brain 1".
3. The system responds: "Brain already exists" even though User B cannot access the original shared brain.
Expected Behavior
- Private brains should allow duplicate names if they belong to different users.
- Shared brains should enforce uniqueness only within the same workspace.
- Users should not be blocked by brains they do not have access to.
Actual Behavior
- The system globally enforces slug uniqueness.
- Even unrelated users or workspaces cannot reuse the same brain name.
Proposed Remediation
- Implement scoped unique indexes:
* Private brains - unique per user
* Shared brains - unique per workspace
- Update pre-save hook logic to validate slug within the correct scope.
- Add automated tests for slug uniqueness handling in both private and shared contexts.
- Apply fix to both Cloud and Open-Source codebases.
Overview
The issue arises from improper scoping of unique slug validation between shared and private brains.
Currently, when a user tries to create a new brain in private mode, the system incorrectly flags it as already existing if any other brain even in a shared workspace or owned by another user has the same slug.
This happens due to missing contextual checks (no differentiation between workspace/user scope in uniqueness validation).
It affects usability and collaboration by preventing legitimate private brain creation.
Affected Endpoint and Files
List the exact API routes, files, and functions involved.
POST /api/brains (Brain creation)PATCH /api/brains/:id (Brain update)server/routes/brain.routes.tsserver/controllers/brain.controller.tspath/to/service.jsSteps to Reproduce
Expected Behavior
Actual Behavior
Proposed Remediation