github/gitlab_issue_assigned: Cancel workflow on unassignment

[mintybasil]

Mistakes happen... It would be nice if a workflow could be cancelled when accidentally triggered. In the case of issue assignment this can easily be mapped to unassigning the issue. We should introduce a boolean config option (cancel_on_unassign) to the github_issue_assigned and gitlab_issue_assigned triggers to enable cancellation when unassignment occurs.

When a workflow is cancelled we should essentially revert to a state as though it was never started. It should not be marked completed or failed, and re-assigning it should result in the same outcome as when it was first assigned.

For the data directory we should move the workspace into a directory called cancelled to preserve what has been done in a way that won't interfere with future runs.

[mintybasil]

@zeroklaw Please can you expand this into a complete epic

[zeroklaw]

Here's the complete epic expansion for #164 — Cancel workflow on unassignment.

---

Problem Statement

When a github_issue_assigned or gitlab_issue_assigned workflow is accidentally triggered, there is currently no way to cancel it. Unassigning the issue (removing the assignee) is a natural inverse of the assignment action that should cancel the in-flight workflow and revert state as though it had never started.

Proposed Approach

Introduce a cancel_on_unassign boolean config option on the Trigger struct (alongside allowed_users). When enabled, receiving an "unassigned" action from the platform webhook cancels any matching in-flight workflow, moves its workspace into a cancelled/ directory, and clears the dedup key so re-assignment triggers a fresh run.

---

Architecture

┌──────────────┐      unassigned event      ┌──────────────────┐
│  Platform     │ ───────────────────────── │  Webhook Handler  │
│  (GitHub/     │                            │  (github.rs /     │
│   GitLab)     │                            │   gitlab.rs)       │
└──────────────┘                            └────────┬─────────┘
                                                     │
                                            ┌────────▼─────────┐
                                            │  New TriggerType  │
                                            │  variants:        │
                                            │  GithubIssueUn-   │
                                            │  assigned         │
                                            │  GitlabIssueUn-   │
                                            │  assigned         │
                                            └────────┬─────────┘
                                                     │
                                            ┌────────▼─────────┐
                                            │   Dispatcher     │
                                            │  (dispatcher.rs) │
                                            │                  │
                                            │  For assign:     │
                                            │   spawn_workflow  │
                                            │                  │
                                            │  For unassign:   │
                                            │   cancel_workflow│
                                            └────────┬─────────┘
                                                     │
                                            ┌────────▼─────────┐
                                            │   Runner /        │
                                            │   Workspace       │
                                            │                   │
                                            │  Move workspace   │
                                            │  → cancelled/     │
                                            │  Clear dedup key  │
                                            └──────────────────┘

---

Sub-tasks

Task 1 — Config: add cancel_on_unassign to Trigger struct

Files: src/workflow.rs, src/config.rs

• Add cancel_on_unassign: Option<bool> (default None → false) to the Trigger struct in src/workflow.rs
• Add #[serde(default)] annotation so existing configs remain valid
• Update Trigger::validate() to enforce that cancel_on_unassign is only set on github_issue_assigned or gitlab_issue_assigned trigger types (reject on all others with a clear error)
• Update TOML docs/examples

Exit criteria: cancel_on_unassign = true accepted on assignment triggers, rejected on others. Existing workflow TOMLs parse without error.

Dependencies: None — this is the foundation.

---

Task 2 — TriggerType: add GithubIssueUnassigned and GitlabIssueUnassigned variants

Files: src/workflow.rs

• Add two new TriggerType variants: GithubIssueUnassigned { assigned_to: Option<String> } and GitlabIssueUnassigned { assigned_to: Option<String> }
• Add string constants in triggers module: GITHUB_ISSUE_UNASSIGNED and GITLAB_ISSUE_UNASSIGNED
• Implement Display, from_trigger(), label(), platform(), webhook_event(), and known_variables() for the new variants
• The webhook_event() should return the same event type as the assignment variants (GitHub: "issues", GitLab: "issues_events") since unassigned comes from the same webhook event type, just with a different action
• The known_variables() should mirror the assignment variants (same template variables available: issue_number, assignee, etc.)

Exit criteria: New variants compile, display correctly, and round-trip through from_trigger → label → from_trigger.

Dependencies: None — can be done in parallel with Task 1.

---

Task 3 — Webhook handlers: detect unassignment events

Files: src/webhook/github.rs, src/webhook/gitlab.rs, src/webhook/mod.rs

• GitHub (github.rs): In map_to_trigger_event(), add a match arm for (GITHUB_ISSUES, "unassigned") → TriggerType::GithubIssueUnassigned { assigned_to }. The assignee field is still present in the payload (it's the user who was unassigned).
• GitLab (gitlab.rs): In map_to_trigger_event(), the IssueHook currently only matches action == "update". Update it to distinguish between assignment and unassignment. GitLab fires "update" action for both — we need to check the payload for assignee changes. If assignees were removed (not just added), emit GitlabIssueUnassigned. If assignees were added, emit GitlabIssueAssigned as before. This requires inspecting the GitLab payload's changes.assignees field (previous vs. current).
• Update src/webhook/mod.rs handle_webhook() if needed to ensure unassign events are dispatched to the dispatcher.

Exit criteria: Unassign webhook payloads from both platforms produce the correct TriggerType variants. Test coverage for both platforms.

Dependencies: Task 2 (new variants must exist).

---

Task 4 — Dispatcher: cancel workflow logic

Files: src/dispatcher.rs

• Add a cancel_workflow method to Dispatcher that:
  1. Looks up the event's dedup key in the in_flight set
  2. If found, signals the running task to cancel (via a CancellationToken or similar mechanism added per spawned task)
  3. On cancellation:
     • Removes the dedup key from in_flight and does NOT add it to completed or permanently_failed
     • Moves the workspace directory from <workdir>/<owner>/<repo>/<event_id>/ to <workdir>/<owner>/<repo>/<event_id>/cancelled/
     • Logs cancellation
  4. If the event is not in-flight (already completed or not found), do nothing — log and return
• Update the dispatch loop to handle the new unassign trigger type:
  • When a GithubIssueUnassigned or GitlabIssueUnassigned trigger event arrives, check whether the matching workflow has cancel_on_unassign = true
  • If yes, call cancel_workflow instead of spawn_workflow
  • If no, ignore the unassign event (log and return)
• Wire a CancellationToken (from tokio_util or a custom AtomicBool) into each spawned workflow task so cancellation can be signaled
• When the cancellation token is set, the runner should stop between steps (not mid-step), not mark the workflow as completed/failed

Exit criteria: An in-flight workflow for an assigned issue can be cancelled via an unassign event. The workspace is moved to cancelled/. The dedup key is cleared so re-assignment triggers a fresh run.

Dependencies: Tasks 1, 2, 3.

---

Task 5 — Runner: graceful cancellation between steps

Files: src/runner.rs

• The runner currently executes steps sequentially. Add a cancellation check between each step:
  • Accept an optional CancellationToken (or AtomicBool) parameter
  • Before each step, check if cancellation was requested; if so, return early with a Cancelled result (not Ok and not an error)
• The Cancelled result should propagate up to the dispatcher, which handles workspace cleanup

Exit criteria: A running workflow stops between steps when cancelled. No partial step execution.

Dependencies: Task 4 (dispatcher needs to pass the cancellation token).

---

Task 6 — Integration tests

Files: tests/dispatcher_tests.rs (new test cases)

• Test: assign → unassign cancels the workflow (config: cancel_on_unassign = true)
• Test: assign → unassign does NOT cancel when cancel_on_unassign = false (or absent)
• Test: cancelled workflow's workspace is moved to cancelled/ subdirectory
• Test: re-assign after cancellation triggers a fresh workflow run
• Test: unassign event for a completed (not in-flight) workflow is a no-op
• Test: cancel_on_unassign on non-assignment triggers is rejected by validation
• Test: GitHub action=unassigned webhook payload produces GithubIssueUnassigned
• Test: GitLab issue update with assignee removal produces GitlabIssueUnassigned

Exit criteria: All tests pass. Coverage for cancellation lifecycle from webhook to workspace cleanup.

Dependencies: Tasks 1–5.

---

Key Design Decisions

1. cancel_on_unassign on Trigger, not TriggerType: Following the pattern established by allowed_users — authorization/behavior config belongs on the Trigger struct, event-content filters (like assigned_to) belong on TriggerType variants.

2. New TriggerType variants for unassigned: Rather than adding an action field to the existing variants, new variants keep the type system honest. Matching a GithubIssueUnassigned trigger type against a github_issue_assigned workflow is a compile-time distinction, not a runtime string comparison.

3. Dedup key is cleared on cancellation: Cancelled workflows should not block re-triggering. Removing the key from all dedup sets (in_flight, completed, permanently_failed) means re-assignment produces a fresh run with a clean workspace. This is the "as though it was never started" semantic the issue requests.

4. Workspace moved, not deleted: Moving to cancelled/ preserves forensic value (logs, step outputs) without interfering with the normal workspace path. A fresh run will create a new workspace at the same original path.

5. Termination between steps, not mid-step: The runner checks cancellation between steps. This is the simplest correct approach — no partial state to clean up, no need for step-level rollback.

Out of Scope

• Cancel on re-assignment (assigning a different user while the first workflow is in-flight) — this is a separate feature
• Cancelling workflows triggered by other event types (only issue_assigned triggers support this initially)
• UI/API for manual workflow cancellation (follow-up: webhook-only cancellation for now)
• Automatic cleanup of cancelled/ directories (follow-up: could add a retention policy)

[mintybasil]

@zeroklaw Please convert this issue into an epic and setup sub-issues as you've described using the Github Relationships feature