platinumhamburg opened a new issue, #3488: URL: https://github.com/apache/fluss/issues/3488
### Search before asking - [x] I searched in the [issues](https://github.com/apache/fluss/issues) and found nothing similar. ### Description ## Background Table and partition directories include stable IDs in their remote paths, so the cleanup action can apply an ID-based guard: - the parsed ID is not in the active ID set - the parsed ID is no greater than the last-known max ID - metadata enumeration must be complete Database directories are different. Their remote paths only contain the database name and do not include a database ID. If a database is deleted and later recreated with the same name, the remote path is indistinguishable from the old one. ## Challenge Database-level orphan cleanup cannot be safely inferred from filesystem paths alone. Without an additional ownership signal, deleting a database directory may accidentally delete data that belongs to a newly recreated database with the same name. Possible prerequisites include one of the following: - database ID in remote paths - database deletion marker or tombstone - coordinator-side deleted database metadata - database-level lock, epoch, or ownership token ## Proposed Direction Treat database-level orphan cleanup as a long-term enhancement. Before implementing it, define a safe ownership model and conservative deletion rules. Until then, the cleanup action should prefer leaking orphan database files over risking accidental deletion. ### Willingness to contribute - [x] I'm willing to submit a PR! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
