Hi @Cheng Shi, @Philip Durbin, and team :wave:
Starting this thread to discuss issue #1073 (https://github.com/IQSS/dataverse-frontend/issues/1073).
Context: While reviewing the file upload flow in UploadedFilesList.tsx, I noticed a couple of TODO comments:
TypeScript
// TODO - Remove the file from the S3 bucket we need an API endpoint for this.
Currently, when files are directly uploaded to S3 and a user later clicks "Remove" (X) or "Remove Selected" from the staging list before saving the dataset, the files are cleared from the frontend form state, but the uploaded objects remain orphaned in the S3 bucket.
Discussion Points:
Should we introduce a backend endpoint in core Dataverse to explicitly delete/abort uncommitted direct upload items?
Or is the intended architecture to rely on S3 lifecycle rules / bucket expiration policies for unreferenced/temp objects?
Would love to hear your thoughts on how we should approach this!
We just talked about this during the frontend meeting and I wanted to at least point out this API endpoint: https://guides.dataverse.org/en/6.12/api/native-api.html#cleanup-storage-of-a-dataset
That endpoint is a way to cleanup orphaned files that were uploaded but never attached to a dataset in a database sense.
@Philip Durbin ๐ Thanks for pointing this out, That makes a lot of sense., Given that api/datasets/{id}/cleanStorage handles sweeping orphaned S3 objects that were never finalized in the database, does the team prefer:, 1. Leaving cleanup entirely to this backend mechanism (and updating/removing the inline TODOs in UploadedFilesList.tsx and FileUploaderPanel.tsx with a reference to this behavior), or, 2. Adding a lightweight, immediate file-level deletion call on the frontend when the user clicks 'Remove' during draft staging?, Happy to adjust the TODO comments or open a PR documenting/handling whichever pattern fits the architecture best!
Hi! First, I wanted to reproduce the bug myself and I just did, leaving a comment here: https://github.com/IQSS/dataverse-frontend/issues/1073#issuecomment-5820169072
I think I like your option 2, that clicking "remove" should remove the file from S3. See also my comment where I clicked "cancel". That should probably be handled too.
Thanks @Philip Durbin ๐ Seeing the LocalStack output makes the issue super clear. Handling both the staged "Remove" action and the page-level "Cancel" button makes complete sense for Option 2.
I just left a follow-up comment on issue exploring whether core Dataverse can issue presigned DELETE tokens for direct uploads or if a dedicated backend endpoint would be needed.
Looking forward to hearing what the team thinks, and I'd love to implement the frontend handling for this once we lock down the backend approach!
I just read your comment in the issue. I don't know anything about presigned DELETE tokens. For now, do you want to try to get a delete working in LocalStack? Maybe we'll learn something. :smile:
Thanks for the suggestion, @Philip Durbin ๐
Currently, my local machine is pretty constrained on disk space and resources, so spinning up the full LocalStack and Dataverse backend Docker containers locally isn't feasible for me right now.
I'm very comfortable handling the React/TypeScript changes once the target delete mechanism or API pattern is established. In the meantime, I'll continue focusing on frontend bug fixes, hook refactoring, and test coverage across dataverse-frontend
Sure, no problem. @Parth karalkar was having the same problem. Dataverse is too fat to run on his local machine. :piglet:
Good to know that you can still do React/TS changes though! :tada:
No, we don't. Can we move that message to its own Zulip topic? Otherwise it's a little buried in this one.
No worries, I deleted the message to keep this thread focused on the issue!
Oh, no worries. It's a good question! :smile: Please feel free to start a new topic in #community or #dev even though you know the answer. :smile:
@Philip Durbin ๐ reading this it makes me wonder if JerseyTests would help with this as well. Maybe spinning up an S3 container is fine, but otherwise not having to deploy all of it just to test an isolated API for file storage would be great, wouldn't it?
Well, the SPA only supports S3. So developers need an S3 service to work on the app.
I just made https://github.com/IQSS/dataverse-frontend/pull/1089 where I'm explaining how to use the S3 file store from the backend dev env.
Last updated: Nov 02 2026 at 07:01 UTC