Service cascade-delete: removing A should remove dependents #66

New issue

Open

opened 2026-04-29 04:22:58 +00:00 by despiegk · 0 comments

despiegk commented

2026-04-29 04:22:58 +00:00

Owner

Context

When a user deletes service A and other services declare requires: [A], those dependents should be deleted too (most-dependent-first). Today service.delete only removes the named service; dependents linger with a dangling requires reference.

Two tests already exist but are #[ignore]d:

tests/integration/tests/service_management.rs:522 — test_remove_parent_stops_children_first — #[ignore = "cascade deletion of dependent services not yet implemented"]
tests/integration/tests/service_management.rs:605 — test_remove_with_dependency_chain — same reason

Repro (from the tests)

A. Parent + one child:

Start cascade-parent, then cascade-child (requires parent). Both reach running.
service_delete({name: "cascade-parent"}).
Expected: both cascade-parent and cascade-child are gone (assert_not_exists).

B. Chain A ← B ← C:

Start all three.
service_delete({name: "chain-rm-a"}).
Expected: all three gone.

Acceptance

service.delete cascades: deletes services with a transitive requires chain into the target before deleting the target.
Order is most-dependent-first; running services are stopped before delete (uses cascade-stop machinery if landed, otherwise stops them inline).
Both ignored tests above are un-ignored and pass.
No regression in test_remove_complete_cleanup (single-service delete still works).
The OpenRPC service.delete result schema gains optional deleted_services count, mirroring the deleted_runs / deleted_jobs pattern from action-delete cascade in #56.

Notes / scope

Same graph traversal as cascade-stop. Implement the graph helper once in hero_proc_lib and use it for both. Likely depends on the cascade-stop issue landing first.
Pattern of inline OpenRPC schema changes: see crates/hero_proc_server/openrpc.json change for action.delete in #56's PR — same approach here.

Follow-up to #56.

## Context When a user deletes service A and other services declare `requires: [A]`, those dependents should be deleted too (most-dependent-first). Today `service.delete` only removes the named service; dependents linger with a dangling `requires` reference. Two tests already exist but are `#[ignore]`d: - `tests/integration/tests/service_management.rs:522` — `test_remove_parent_stops_children_first` — `#[ignore = "cascade deletion of dependent services not yet implemented"]` - `tests/integration/tests/service_management.rs:605` — `test_remove_with_dependency_chain` — same reason ## Repro (from the tests) A. Parent + one child: 1. Start `cascade-parent`, then `cascade-child` (requires parent). Both reach `running`. 2. `service_delete({name: "cascade-parent"})`. 3. Expected: both `cascade-parent` and `cascade-child` are gone (`assert_not_exists`). B. Chain A ← B ← C: 1. Start all three. 2. `service_delete({name: "chain-rm-a"})`. 3. Expected: all three gone. ## Acceptance - `service.delete` cascades: deletes services with a transitive `requires` chain into the target before deleting the target. - Order is most-dependent-first; running services are stopped before delete (uses cascade-stop machinery if landed, otherwise stops them inline). - Both ignored tests above are un-ignored and pass. - No regression in `test_remove_complete_cleanup` (single-service delete still works). - The OpenRPC `service.delete` result schema gains optional `deleted_services` count, mirroring the `deleted_runs` / `deleted_jobs` pattern from action-delete cascade in #56. ## Notes / scope - Same graph traversal as cascade-stop. Implement the graph helper once in `hero_proc_lib` and use it for both. Likely depends on the cascade-stop issue landing first. - Pattern of inline OpenRPC schema changes: see `crates/hero_proc_server/openrpc.json` change for `action.delete` in #56's PR — same approach here. Follow-up to #56.