[Enhancement]: Store uploaded files per conversation (userId/conversationId)

[marbence101]

What features would you like to see added?

Currently uploaded files are stored only at the user level, which makes it harder to manage files per conversation—for example for cleanup, isolation, auditing, and organization.

Could we please add support for storing uploads using a per-conversation path such as
{userId}/{conversationId}/{filename}?

Thanks so much!

More details

N/A

Which components are impacted by your request?

General

Pictures

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[danny-avila]

Thanks for the suggestion! This is actually already handled, every File document stores indexed user, conversationId, and messageId fields, and the conversation document itself has a files array that references its associated files directly. So files are already fully associated with their conversation at both ends of the relationship.

Cleanup, isolation, auditing, and organization can all be done through these existing associations without any changes to how files are physically stored. Embedding conversationId in the storage path would add complexity to path construction and file access without providing any capability that isn't already available.

If there's a specific workflow that feels broken or missing (e.g., files not being cleaned up when a conversation is deleted), a more targeted issue would be very welcome!

[marbence101]

Thank you very much for the answer!

Yes, extracting it from MongoDB is a viable solution. However, I’ve encountered an issue where the files in the files table don't have a conversationId assigned to them; I can only retrieve that connection through the conversations table. This isn't a problem in itself, as I've managed to implement filtering based on this, so it works.

The real issue is that when I start a new conversation, a UUID only seems to be generated after the very first LLM response. If I upload files with the initial message and want to use them immediately (for example, in an MCP request), I can't do so because the association hasn't been created yet—even though the files are physically stored in S3, the database record in MongoDB only gets updated after the message response.