FlowiseAI/Flowise · error · InternalFlowiseError

Error: chatMessagesController.removeAllChatMessages - worksp

Error message

Error: chatMessagesController.removeAllChatMessages - workspace ${workspaceId} not found!

What it means

Thrown by removeAllChatMessages when the authenticated user's JWT/session has no activeWorkspaceId. The guard reads req.user?.activeWorkspaceId and rejects with HTTP 404 (NOT_FOUND) when it is absent. It fires before any chatflow lookup, so no DB access has occurred yet. The 404 is somewhat misleading — the real cause is an incompletely populated user context, not a missing record.

Source

Thrown at packages/server/src/controllers/chat-messages/index.ts:163

const removeAllChatMessages = async (req: Request, res: Response, next: NextFunction) => {
    try {
        const appServer = getRunningExpressApp()
        if (typeof req.params === 'undefined' || !req.params.id) {
            throw new InternalFlowiseError(
                StatusCodes.PRECONDITION_FAILED,
                'Error: chatMessagesController.removeAllChatMessages - id not provided!'
            )
        }
        const orgId = req.user?.activeOrganizationId
        if (!orgId) {
            throw new InternalFlowiseError(
                StatusCodes.NOT_FOUND,
                `Error: chatMessagesController.removeAllChatMessages - organization ${orgId} not found!`
            )
        }
        const workspaceId = req.user?.activeWorkspaceId
        if (!workspaceId) {
            throw new InternalFlowiseError(
                StatusCodes.NOT_FOUND,
                `Error: chatMessagesController.removeAllChatMessages - workspace ${workspaceId} not found!`
            )
        }
        const chatflowid = req.params.id
        const chatflow = await chatflowsService.getChatflowByIdForWorkspace(req.params.id, workspaceId)
        if (!chatflow) {
            return res.status(404).send('Chatflow not found')
        }
        const flowData = chatflow.flowData
        const parsedFlowData: IReactFlowObject = JSON.parse(flowData)
        const nodes = parsedFlowData.nodes
        const chatId = req.query?.chatId as string
        const memoryType = req.query?.memoryType as string | undefined
        const sessionId = req.query?.sessionId as string | undefined
        const _chatTypes = req.query?.chatType as string | undefined
        let chatTypes: ChatType[] | undefined
        if (_chatTypes) {

View on GitHub (pinned to abe4a8601a)

Solutions

Confirm the caller's session/JWT actually contains a workspace claim — decode the token and check activeWorkspaceId is present.
Verify the user has a workspace_user row for the target workspace; if not, have an org admin add the membership.
Check auth middleware ordering: the middleware that resolves activeWorkspaceId must run before this controller on the route.
If integrating programmatically, ensure your login flow selects/switches into a workspace so the claim is populated.
Long-term: file an issue — this should be 401/403, not 404, since the resource isn't what's missing.

Example fix

// before: caller has token with no workspace claim
// after: log in and select a workspace so JWT includes activeWorkspaceId
await api.post('/auth/login', creds)
await api.post('/workspaces/select', { workspaceId })
await api.delete(`/api/v1/chatmessages/${chatflowId}`)

Defensive patterns

Strategy: validation

Validate before calling

function hasWorkspaceClaim(user): boolean {
  return Boolean(user && (user as any).activeWorkspaceId)
}
// before calling delete:
if (!hasWorkspaceClaim(currentUser)) {
  // re-auth / select workspace instead of calling the endpoint
}

Type guard

function hasWorkspaceContext(u: unknown): u is { activeWorkspaceId: string; activeOrganizationId: string } {
  return typeof u === 'object' && u !== null
    && typeof (u as any).activeWorkspaceId === 'string' && (u as any).activeWorkspaceId.length > 0
    && typeof (u as any).activeOrganizationId === 'string' && (u as any).activeOrganizationId.length > 0
}

Prevention

Always run workspace selection after login so the JWT carries activeWorkspaceId.
In integration tests, populate req.user fully — including activeWorkspaceId and activeOrganizationId.
Build a central requireWorkspace() client guard and call it before any workspace-scoped endpoint.
Decode the JWT in a dev helper to confirm claims before debugging controller errors.

When it happens

Trigger: Calling DELETE /api/v1/chatmessages/:id after authentication middleware set req.user but did not attach activeWorkspaceId (e.g. user belongs to no workspace, workspace membership row missing, or a stale token minted before workspace assignment). Also reachable if the auth middleware was bypassed or partially applied on a custom route.

Common situations: Newly invited user whose workspace membership DB row hasn't propagated; JWT signed without workspace claim after an org/workspace migration; test harness that stubs req.user with only id and activeOrganizationId; multi-tenant rework where activeWorkspaceId resolution moved to a later middleware that didn't run.

Related errors

AI-assisted analysis of FlowiseAI/Flowise@abe4a8601a (2026-08-12). Data as JSON: /api/errors/26a5312a7b485308. Report an issue: GitHub.