Description

When a file is uploaded during a chat session via POST /api/v1/documents/upload (or the equivalent frontend flow), it is stored in MinIO under the bucket {user_id}-downloads with a UUID key. No database record is created for this object.

When the corresponding chat session is later deleted (DELETE /api/v1/chats/{chat_id}/sessions), the blob in MinIO is never removed, resulting in orphaned objects that accumulate indefinitely.

Steps to reproduce

1. Create a chat session
2. Upload a file via the chat interface (file is stored in {user_id}-downloads MinIO bucket)
3. Delete the session via DELETE /api/v1/chats/{chat_id}/sessions with {"ids": ["<session_id>"]}
4. Check MinIO: the blob still exists in {user_id}-downloads

Expected behavior

Deleting a session should cascade-delete all associated file blobs from the storage backend.

Current behavior

ConversationService.delete_by_id(sid) removes the DB record but never calls any storage cleanup. The MinIO objects referenced in conv.message[].files[] are left as orphans.

Root cause

In api/apps/restful_apis/chat_api.py, delete_sessions (and delete_all path) only calls ConversationService.delete_by_id(sid) without iterating over attached files to remove them from storage.

Proposed fix

Before calling delete_by_id, iterate over conv.message[].files[] and remove each blob:

ok, conv = ConversationService.get_by_id(sid)
if ok:
    for msg in (conv.message or []):
        for f in (msg.get("files") or []):
            try:
                bname = f"{f['created_by']}-downloads"
                settings.STORAGE_IMPL.rm(bname, f["id"])
            except Exception:
                logging.warning("Failed to delete blob %s/%s", f.get("created_by"), f.get("id"))
ConversationService.delete_by_id(sid)

Question before submitting a PR

Issues #6811 and #9831 suggest a potential architectural rework of how chat file uploads are handled (session-scoped vs. permanent storage). Is a broader refactor of the file lifecycle planned? If so, a PR fixing the current behavior may not be worth the effort.

Environment

• RAGFlow version: tested against current main
• Storage backend: MinIO (likely affects S3 as well)

Related issues

• [Question]: The issue regarding the automatic saving of attachments uploaded in the chat window to the knowledge base #6811 — Chat attachments stored permanently instead of session-scoped
• [Question]: How to upload temporary files during a CHAT SESSION using the HTTP API #9831 — No API to upload temporary files for a chat session
• [Question]: Why is the file information placed in the knowledge base instead of the user message, when uploading files in chat? #6641 — Why is file info placed in KB instead of user message?