[CLN]: remove v1 of garbage collection

[codetheweb]

Description of changes

Removes a bunch of dead code.

Test plan

How are these changes tested?

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

Migration plan

Are there any migrations, or any forwards/backwards compatibility changes needed in order to make sure this change deploys reliably?

Observability plan

What is the plan to instrument and monitor this change?

Documentation Changes

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

[codetheweb]

• [ENH]: use FSTs for garbage collection #5628
• [CLN]: remove v1 of garbage collection #5627 👈 (View in Graphite)
• main

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

[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)

[propel-code-bot]

Remove Legacy Garbage Collection v1 Code

This PR removes the original (v1) implementation of garbage collection logic from the codebase, including related orchestrators, operators, tests, and support code. The system is now fully migrated to the v2 garbage collection implementation, simplifying the codebase and eliminating duplicate/dead code across several modules. The removal includes substantial refactoring of type definitions, orchestrator handling, and extensive deletions from test and property test code, as well as API/CLI surface changes to fully deprecate v1 pathways.

Key Changes

• Deleted the entire rust/garbage_collector/src/garbage_collector_orchestrator.rs and related v1 test files
• Removed all references to v1 orchestrator and v1 operator classes from the codebase (e.g., orchestrator creation logic, tests, helper code)
• Refactored CleanupMode enum in rust/garbage_collector/src/types.rs to only retain v2 and soft delete options; removed v1 options
• Updated logic throughout the code to use only v2 GC modes (DryRunV2, DeleteV2, Rename), including operator behavior and test logic
• Cleaned up public APIs and struct definitions to remove all functions/signatures specific to v1 GC
• Removed v1-specific error mappings and orchestration logic from garbage_collector_component
• Updated property and integration tests to only exercise v2 codepaths

Affected Areas

• rust/garbage_collector/src/garbage_collector_orchestrator.rs (complete removal)
• rust/garbage_collector/src/garbage_collector_component.rs
• rust/garbage_collector/src/types.rs
• rust/garbage_collector/src/operators/delete_unused_files.rs
• rust/garbage_collector/src/operators/delete_unused_logs.rs
• rust/garbage_collector/src/helper.rs
• rust/garbage_collector/tests/prop_test_local_files.rs
• rust/garbage_collector/tests/proptest_helpers/garbage_collector_under_test.rs
• Cargo/tests and module registration (rust/garbage_collector/src/lib.rs)

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