[ENH]: perform collection hard deletes from garbage collector

[codetheweb]

Description of changes

This updates the garbage collector to transition soft deleted collections to hard deleted when eligible.

Test plan

How are these changes tested?

• Tests pass locally with pytest for python, yarn test for js, cargo test for rust

I updated the proptest with a new transition for deleting collections.

Documentation Changes

Are all docstrings for user-facing APIs updated if required? Do we need to make documentation changes in the docs section?

n/a

[github-actions]

Reviewer Checklist

Please leverage this checklist to ensure your code review is thorough before approving

Testing, Bugs, Errors, Logs, Documentation

• Can you think of any use case in which the code does not behave as intended? Have they been tested?
• Can you think of any inputs or external events that could break the code? Is user input validated and safe? Have they been tested?
• If appropriate, are there adequate property based tests?
• If appropriate, are there adequate unit tests?
• Should any logging, debugging, tracing information be added or removed?
• Are error messages user-friendly?
• Have all documentation changes needed been made?
• Have all non-obvious changes been commented?

System Compatibility

• Are there any potential impacts on other parts of the system or backward compatibility?
• Does this change intersect with any items on our roadmap, and if so, is there a plan for fitting them together?

Quality

• Is this code of a unexpectedly high quality (Readability, Modularity, Intuitiveness)

[codetheweb]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• [ENH]: soft delete databases, add FinishDatabaseDeletion gRPC method to hard delete databases #4627
• [ENH]: perform collection hard deletes from garbage collector #4605 👈 (View in Graphite)
• [ENH]: sysdb changes to support moving collection hard deletes to garbage collector #4607
• [ENH]: add validation during garbage collection for empty file paths #4586
• [ENH]: garbage collector v2 orchestrator (supports forking) #4468
• [ENH]: allow deleting v0 from version file & correctly propagate errors on DeleteCollectionVersion #4579
• [ENH]: add operator for garbage collection to list all files used by collection version #4466
• [ENH]: add operator to compute versions to garbage collect from version graph #4464
• [ENH]: add orchestrator to construct version graph for garbage collection #4463
• [ENH]: add batch get version file paths method to Sysdb #4432 : 1 other dependent PR (#4447 )
• [ENH]: SysDb should return lineage, version file paths and root collection ID on collections #4557
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[codetheweb]

changes in this file provide a little more debugging info + a new defensive check

[propel-code-bot]

Garbage Collector Now Transitions & Finalizes Hard Deletes of Soft-Deleted Collections

This PR refactors and extends the garbage collection system to fully support and perform hard deletion of collections once they have been soft deleted and all eligible versions are pruned. The hard-delete process is now handled within the garbage collector, with systematic checks to ensure no dependent forked collections remain alive before escalation from soft to hard delete, and includes batch APIs to check and finalize deletion status through sysdb. Comprehensive changes span orchestrators, computation operators, sysdb, test harnesses, and the supporting types.

Key Changes:
• Garbage Collector orchestrator expanded to process soft-deleted collections, transitioning them to hard-deleted after all fork descendants are soft deleted.
• Introduced batch_get_collection_soft_delete_status and finish_collection_deletion funcs in sysdb (and GrpcSysDb), including wire-up from orchestrator.
• Operators and orchestrators now propagate soft delete status and ensure versions in soft-deleted collections are always marked for deletion.
• Testing harness and proptests upgraded to validate soft→hard delete transitions and invariants, with new tests for forked/fan-out scenarios.
• Defensive checks and improved debug output for graph invariants and connectivity added to version graph construction.
• API/types expanded for new sysdb batch soft delete status logic.

Affected Areas:
• garbage_collector/orchestrator_v2.rs
• garbage_collector/operators/compute_versions_to_delete_from_graph.rs
• garbage_collector/tests/proptest_helpers/garbage_collector_reference.rs
• garbage_collector/tests/proptest_helpers/garbage_collector_under_test.rs
• sysdb.rs, test_sysdb.rs
• types/api_types.rs
• construct_version_graph_orchestrator.rs

Potential Impact:

Functionality: Introduces new behavior: soft-deleted collections are only fully (hard) deleted by GC after all forked descendants are also soft-deleted; ensures safe pruning and data integrity.

Performance: Minimal overhead added by extra sysdb checks; batch queries optimize status retrieval. No major regressions expected.

Security: No sensitive security changes. Preserves integrity by ensuring hard deletes only when structurally safe.

Scalability: Batch operations and targeted traversal optimize handling for large numbers of collections/forks. Safe for scale.

Review Focus:
• Correctness of soft→hard delete state transition (including forked collections).
• That all sysdb/Grpc interfaces are called safely and with anticipated parameters.
• Tests cover edge conditions: forking, simultaneous deletes, partial deletion trees.
• Defensive checks for graph connectivity, and proper error escalation.
• Thread safety and error handling in new async sysdb/batch methods.

Testing Needed

• Run and inspect all proptests (now covering fork and soft/hard delete edge cases).
• Exercise full fork-and-delete lifecycles; verify that collections only disappear when all descendants are deleted.
• Confirm sysdb batch status matches expectations after GC runs.
• Check debug output and graph connectivity invariants in unusual topologies.

Code Quality Assessment

rust/garbage_collector/src/garbage_collector_orchestrator_v2.rs: Expanded state, control flow, and error handling; separation of soft/hard delete stages is clear.

rust/garbage_collector/src/operators/compute_versions_to_delete_from_graph.rs: Correct separation of logic for normal and soft-deleted collections; new tests clear.

rust/sysdb/src/sysdb.rs: Well-organized batch and finalize APIs; explicit errors and branching for mode.

rust/sysdb/src/test_sysdb.rs: Test helpers now properly simulate new logic.

rust/types/src/api_types.rs: New enums for batch status errors, well-integrated.

rust/garbage_collector/src/construct_version_graph_orchestrator.rs: Defensive, additional error cases; clear.

rust/garbage_collector/tests/proptest_helpers/garbage_collector_reference.rs: Significant refactor and logic addition; explicit, well-annotated. Edge-cases covered.

Best Practices

Error Handling:
• Explicit error propagation
• Defensive checks for invariants and graph structure

Test Coverage:
• Extended and edge-case property tests for all critical new paths

API Design:
• Batch interfaces
• Clear, explicit state transitions

Potential Issues

• If forks are created or deleted rapidly in pathological topologies, timing bugs or race conditions could occur in hard delete escalation (should be caught by proptests).
• Batch sysdb calls may need further optimization or retries if underlying storage becomes inconsistent.
• Backward compatibility for sysdb implementations not supporting new batch/check/finalize APIs is not fully maintained; TODOs present for sqlite/test.

This summary was automatically generated by @propel-code-bot