feat: delete graph and pending execution

[NiveditJain]

Add UI-based feature to cancel graph templates and pending executions.

Motivation

1. Lifecycle management – Users need to remove graph templates that are no longer needed, deprecated, or replaced by newer versions.
2. Resource cleanup – Cancel long-running or stuck executions to free up resources and prevent unnecessary processing.
3. Cost control – Stop executions that are consuming resources but no longer needed (e.g., test runs, cancelled operations).
4. Operational control – Provide users with the ability to manage their workflows and executions through the dashboard without requiring API access.

Current State

What Exists

Component	Location	Purpose
Graph Templates	Dashboard "Graph" tab	View and edit graph templates
Runs Table	Dashboard "Runs" tab	View execution history and status
Graph Visualization	Dashboard	View individual run execution details
Graph Template Detail Modal	Dashboard	View graph template configuration

Current Limitations

• No UI option to delete graph templates
• No UI option to cancel running executions
• Users must use API directly or manually clean up resources
• No visibility into what happens when a run is cancelled
• No bulk operations for managing multiple executions

Proposed Solution

Feature 1: Delete Graph Template

Allow users to delete graph templates from the dashboard. This should:

• Remove the graph template definition
• Optionally handle existing runs (warn about active executions)
• Provide confirmation dialog to prevent accidental deletion
• Show impact (number of runs, active executions) before deletion

Feature 2: Cancel Pending Executions

Allow users to cancel running or pending executions (runs) from the dashboard. This should:

• Cancel runs that have pending states (CREATED, QUEUED, EXECUTED)
• Mark cancelled runs appropriately in the UI
• Show which states were cancelled vs completed
• Provide feedback on cancellation status

User Experience

Delete Graph Template Flow

1. Access point: Delete button/action in Graph Template Detail modal or Graph Template list
2. Confirmation dialog:
   • Show graph name and namespace
   • Display warning about impact (e.g., "This will delete the graph template. X runs exist for this graph.")
   • Option to also cancel active runs
   • Require explicit confirmation (type graph name or click confirm)
3. Result:
   • Graph template is removed
   • User sees success message
   • Graph no longer appears in lists
   • Optionally: Active runs are cancelled (if user selected that option)

Cancel Execution Flow

1. Access point: Cancel button in Runs Table for runs with pending states
2. Confirmation dialog:
   • Show run ID and graph name
   • Display current status (e.g., "3 states pending, 5 states completed")
   • Explain what will happen (pending states will be cancelled)
3. Result:
   • Run status changes to "Cancelled"
   • Pending states are marked as cancelled
   • User sees success message
   • Run appears with cancelled status in runs table

Visual Indicators

• Delete button: Red/destructive styling, trash icon
• Cancel button: Warning styling, stop/cancel icon
• Cancelled runs: Distinct status badge/color in runs table
• Graphs with active runs: Warning indicator if deletion would affect active runs

Use Cases

Use Case 1: Remove Deprecated Graph

Scenario: User has an old graph template that's been replaced by a newer version.

User action:

1. Navigate to Graph Templates
2. Open the old graph template
3. Click "Delete" button
4. Review confirmation dialog showing "15 runs exist for this graph"
5. Confirm deletion
6. Graph is removed from the system

Expected outcome: Graph template is deleted. Historical runs remain for reference but no new executions can be triggered.

Use Case 2: Stop Long-Running Test Execution

Scenario: User triggered a test run that's taking too long or is no longer needed.

User action:

1. Navigate to Runs table
2. Find the running execution
3. Click "Cancel" button on the run row
4. Review confirmation showing "8 states pending"
5. Confirm cancellation
6. Run is cancelled

Expected outcome: Run status changes to "Cancelled". Pending states are marked as cancelled and won't be executed. Completed states remain visible for reference.

Use Case 3: Clean Up Failed Test Runs

Scenario: User has multiple failed test runs cluttering the runs table.

User action:

1. Navigate to Runs table
2. Filter or select multiple failed runs
3. Use bulk cancel/delete action (future enhancement)
4. Confirm bulk operation

Expected outcome: Selected runs are cancelled or marked for cleanup.

Use Case 4: Delete Graph with Active Executions

Scenario: User wants to delete a graph but there are currently running executions.

User action:

1. Navigate to Graph Templates
2. Attempt to delete graph with active runs
3. See warning: "Cannot delete: 3 active executions in progress"
4. Option to cancel active runs first, then delete
5. Or wait for executions to complete, then delete

Expected outcome: User is informed about active executions and guided on how to proceed.

Acceptance Criteria

Delete Graph Template

• Delete button/action available in Graph Template UI
• Confirmation dialog shows graph details and impact
• Warning displayed if graph has active runs
• Graph template is removed from system after confirmation
• Success message displayed after deletion
• Deleted graph no longer appears in graph lists
• Historical runs remain accessible (not deleted)

Cancel Execution

• Cancel button available in Runs Table for runs with pending states
• Cancel button only shown for cancellable runs (has pending states)
• Confirmation dialog shows run details and pending state count
• Run status changes to "Cancelled" after confirmation
• Pending states are marked as cancelled
• Success message displayed after cancellation
• Cancelled runs are clearly distinguished in UI
• Completed states remain visible (not deleted)

UI/UX

• Destructive actions (delete, cancel) use appropriate styling (red/warning colors)
• Confirmation dialogs prevent accidental actions
• Clear feedback messages for success and error cases
• Loading states shown during operations
• Error handling with user-friendly messages
• Actions are accessible from relevant UI locations

Edge Cases

• Handle deletion of graph with no runs
• Handle cancellation of run with no pending states (button disabled)
• Handle cancellation of already completed run (show appropriate message)
• Handle network errors during deletion/cancellation
• Handle concurrent operations (multiple users)

Non-Goals

• Bulk operations – Single graph/run operations only (bulk can be future enhancement)
• API-only operations – Focus on UI, API changes are implementation detail
• Automatic cleanup – Manual user-initiated actions only
• State-level cancellation – Cancel entire runs, not individual states
• Recovery/undo – Deletions and cancellations are permanent (with appropriate warnings)

Open Questions

1. Soft delete vs hard delete: Should deleted graphs be recoverable, or permanently removed?
2. Run cleanup: Should cancelled runs be automatically cleaned up after some time, or remain forever?
3. Permissions: Should there be role-based access control for delete/cancel operations?
4. Audit trail: Should deletions and cancellations be logged/audited for compliance?
5. Cascading effects: If a graph is deleted, what happens to scheduled triggers (cron jobs)?
6. Partial cancellation: Can users cancel specific states within a run, or only the entire run?

Additional Notes

• This feature focuses on user-facing functionality and UI/UX, not implementation details
• Implementation should ensure data consistency and proper cleanup of resources
• Consider integration with feature-plan feat: Add support for webooks #633 (alerts) - cancellation events could trigger notifications
• Future enhancements could include: bulk operations, scheduled cleanup, undo functionality, audit logs