@Marvin I deleted a flow through an API call; looked at the https://api.prefect.cloud/api/accounts/{{account_id}}/events/filter api call to confirms that it was deleted. the returned payload has a term

"prefect.delete-stage": "soft"

for this call. my ui still has the flow on a schedule; please explain. thanks

Deleting a flow in Prefect Cloud triggers a "soft delete" (

"prefect.delete-stage": "soft"

), which means the flow is hidden but not fully removed from the system. This can lead to some residual effects, such as the flow continuing to appear on schedules. This behavior occurs because deleting a flow does not automatically delete the associated deployments or scheduled tasks, leading to orphaned deployments. This issue is documented in Prefect's GitHub issues. For example, Issue #9856 notes that deleting a flow will not delete its associated deployments. If these deployments are scheduled, they will continue to trigger based on their schedule, potentially causing errors when trying to run the orphaned deployments. Here are the key points from the issue: - When deleting a flow, deployments for that flow are not deleted. - Scheduled deployments will continue to run despite the flow being deleted. - These orphaned deployments lead to errors because the associated flow is missing. - There is no immediate way to navigate to these orphaned deployments in the UI unless known. ### Steps to resolve: 1. Manually identify and delete the associated deployments for the flow. 2. Clean up any external resources or manually remove schedules related to the deleted flow. For additional help, please refer to: - GitHub Issue #9856 - Prefect Docs on artifacts management, which explains some aspects of managing flows and artifacts. If you need more detailed steps or run into other issues, feel free to ask!

@Marvin can you explain more the soft delete

The concept of "soft delete" in Prefect means that an entity (such as a flow) is not permanently removed from the database or system. Instead, it is marked as deleted and hidden from the user interface but still exists in the backend. ### Details on Soft Delete: 1. Visibility: - The item marked for soft deletion no longer appears in the UI or API calls that list items; however, it remains in the database. - This approach ensures that the data can be recovered or audited later if necessary. 2. Impact on Related Objects: - Soft deleting a flow does not automatically delete its associated deployments or scheduled tasks. As these scheduled deployments remain active, they can still be triggered, which causes errors when they attempt to run the deleted flow. - This is the reason you still see scheduled runs even after the soft deletion of a flow. 3. Rationale: - The rationale behind soft deletion is often to keep historical data for audit purposes or potential recovery. - It allows the system to maintain references to these objects without breaking referential integrity in the database. 4. Actions to Take: - To avoid issues with orphaned deployments, you should manually delete associated deployments when you soft delete a flow. - Regular maintenance might be required to clean up any residual data to keep the system clean and avoid unexpected behaviors. ### Sources: - Issue #9856 on GitHub - Prefect documentation and general understanding of soft delete concepts In summary, soft deleting a flow ensures that it is no longer active or visible but still retains its data in the backend. This necessitates manual cleanup of related deployments to prevent them from erroneously executing in the future. If you need further assistance or run into other issues, feel free to reach out!