Deleting an application leaves its routes behind — CF's v3 API never cascades routes on app delete (the cf CLI's delete -r is client-side behavior), and the current Stratos delete paths (single-app confirm and bulk delete) only delete the app. In practice this accumulates orphaned routes: one test space was found holding 48 routes for 5 apps, 44 of them bound to nothing, with hostnames tracing back to deleted sample apps and test runs.
This is restoration work, not a new feature: the v4.9.2 Delete Application stepper had a Routes step ("Please select any attached application routes you would like to delete") and an equivalent for service instances. The signal migration's delete flows dropped it.
Pieces already in place:
- Routes carry their bound apps (
appGuids), so an app's routes resolve client-side from data already loaded.
- The backend already exposes bulk route delete/unmap endpoints.
- The e2e cleanup helper already encodes the required ordering (delete routes before the app).
Landing options: an "also delete this app's routes" option on the existing single/bulk delete confirmations (lightweight), or a restored v4-style selection step (heavier; also covers service-instance co-delete).
One semantic to get right: a route with multiple destinations must not be deleted when only one of its apps is — the v4 selector made this visible; any cascade-style option needs to skip or call out multi-destination routes.
Deleting an application leaves its routes behind — CF's v3 API never cascades routes on app delete (the cf CLI's
delete -ris client-side behavior), and the current Stratos delete paths (single-app confirm and bulk delete) only delete the app. In practice this accumulates orphaned routes: one test space was found holding 48 routes for 5 apps, 44 of them bound to nothing, with hostnames tracing back to deleted sample apps and test runs.This is restoration work, not a new feature: the v4.9.2 Delete Application stepper had a Routes step ("Please select any attached application routes you would like to delete") and an equivalent for service instances. The signal migration's delete flows dropped it.
Pieces already in place:
appGuids), so an app's routes resolve client-side from data already loaded.Landing options: an "also delete this app's routes" option on the existing single/bulk delete confirmations (lightweight), or a restored v4-style selection step (heavier; also covers service-instance co-delete).
One semantic to get right: a route with multiple destinations must not be deleted when only one of its apps is — the v4 selector made this visible; any cascade-style option needs to skip or call out multi-destination routes.