You have a new entry in file storage, where you must track this association with a user or a chat, to persist the download longer than the session or to expire it or delete it as part of thread chat maintenance.
This answer makes sense. However, I am able to access files from a conversation I started yesterday with no problems. This implies the files are not associated with the code interpreter sessions and instead, they persist for an undefined duration. Perhaps they are forever condemned to clutter my file storage, or perhaps they are erased along with the threads.
It would be nice to know what the default behaviour is so that I know what kind of manual management of these files I should perform. Setting up a regular routine to erase or persist old files isn’t a problem, but I would like to understand the default behaviour.
Yes, you are correct the files are created, and the files endpoint doesn’t have any expiration method.
What I was trying to impress upon you was the need for your own maintenance, due to built-in loss of connection to the files, that you have to scrape out of responses, as the reset code interpreter would no longer have result files to continue working on, and that there is no cleanup.
Then basically need to have your own information client-side about a chat anyway to map users to threads, cache and provide metadata like chat titles, persist connection to user-created data, either uploads or outputs, to make chats continue to be accessible after inactivity or to synchronize with the expected inactivity deletion of a thread, performing more processes, making the whole Assistants platform rather pointless once you’d set up Juptyterhub or other notebook virtualization environment, or real script file+execute environment.