bytedance/deer-flow · error · HTTPException

Failed to clear memory data.

Error message

Failed to clear memory data.

What it means

500 raised when MemoryManager.clear_memory raises OSError — an I/O-level failure deleting or rewriting the memory persistence files for the resolved user. Manager-level logical failures have their own mappings (NotImplementedError->501, MemoryConflictError/MemoryCorruptionError->mapped); this catch is strictly for filesystem errors such as permission denied or IO errors during the clear.

Source

Thrown at backend/app/gateway/routers/memory.py:300

@router.delete(
    "/memory",
    response_model=MemoryResponse,
    response_model_exclude_none=True,
    summary="Clear All Memory Data",
    description="Delete all saved memory data and reset the memory structure to an empty state.",
)
async def clear_memory(http_request: Request) -> MemoryResponse:
    """Clear all persisted memory data."""
    manager = await asyncio.to_thread(get_memory_manager)
    try:
        memory_data = await asyncio.to_thread(manager.clear_memory, user_id=_resolve_memory_user_id(http_request))
    except NotImplementedError:
        raise _unsupported_501(manager, "clear memory") from None
    except (MemoryConflictError, MemoryCorruptionError) as exc:
        raise _map_memory_manager_error(exc) from exc
    except OSError as exc:
        raise HTTPException(status_code=500, detail="Failed to clear memory data.") from exc

    return MemoryResponse(**memory_data)


@router.post(
    "/memory/facts",
    response_model=MemoryResponse,
    response_model_exclude_none=True,
    summary="Create Memory Fact",
    description="Create a single saved memory fact manually.",
)
async def create_memory_fact_endpoint(request: FactCreateRequest, http_request: Request) -> MemoryResponse:
    """Create a single fact manually."""
    manager = await asyncio.to_thread(get_memory_manager)
    try:
        memory_data, fact_id = await asyncio.to_thread(
            manager.create_fact,
            content=request.content,

View on GitHub (pinned to 1dd6ba1acb)

Solutions

1. Check Gateway logs for the OSError details (errno/path) chained to this 500
2. Fix ownership/permissions on the memory storage directory so the Gateway process can read, write, and delete files in it
3. Ensure only one Gateway process uses the memory path, or move to a backend that supports your concurrency model
4. Retry once after fixing permissions — clear is idempotent

Example fix

# shell: fix container volume ownership that caused EACCES
# before: memory dir owned by root, Gateway runs as app-user -> 500
# after
chown -R app-user:app-user /data/memory && chmod u+rwX /data/memory
# then retry POST /api/memory/clear

null

null

try { await clearMemory(); } catch (e) { if (e.status === 500) { notify('clear failed — check storage permissions; safe to retry'); await delay(1000); return clearMemory(); /* idempotent */ } throw e; }

When it happens

Trigger: DELETE-like clear endpoint invoked when the memory store directory is not writable by the Gateway process; the memory file is held/locked by another process; disk-full during the rewrite; NFS/overlayfs returning EACCES or EIO on unlink.

Common situations: Container deployments with wrong volume ownership for the memory directory; multiple Gateway instances pointing at one memory path; storage backend transient failures; restrictive SELinux/AppArmor policies.

Related errors

• Failed to update user profile: {str(e)}
• Failed to create memory fact.
• Failed to delete memory fact.
• Failed to update memory fact.
• Failed to import memory data.

AI-assisted analysis of bytedance/deer-flow@1dd6ba1acb (2026-08-14). Data as JSON: /api/errors/861f11f4d0cfdbb1. Report an issue: GitHub.