bug: status comment orphaned on hard process termination (SIGKILL/OOM)

[mysticgohan1]

What happens

When the fullsend run process is terminated abruptly — SIGKILL, OOM kill, segfault, or equivalent — the deferred PostCompletion call in runAgent never runs. Any "Started" status comment already posted on the issue/PR remains permanently, with no terminal outcome.

This is distinct from workflow cancellation handled via SIGTERM/signal.NotifyContext (see fullsend-ai#2147, PR fullsend-ai#2146): those paths rely on the Go process unwinding and running defers. Hard kills bypass defer execution entirely.

What should happen

Users should not be left with a misleading "Started" comment that implies an agent is still running when the process is gone. The desired behavior on hard termination is an open design question — in-process recovery may be impossible — but the gap should be acknowledged and tracked.

Context

The status comment lifecycle is managed by a defer in runAgent (internal/cli/run.go) that calls statuscomment.Notifier.PostCompletion. This mechanism covers normal returns, error returns, and (after PR fullsend-ai#2146) SIGTERM-driven cancellation when the process unwinds cleanly.

Hard termination is the remaining in-process blind spot. Observed in production-adjacent scenarios when CI runners kill jobs without a graceful window, or when the process is OOM-killed during heavy agent workloads.

Follow-up to fullsend-ai#2147 and PR fullsend-ai#2146.

[mysticgohan1]

/fs-triage

[fullsend-ai-triage]

🤖 Finished Triage · ✅ Success · Started 6:43 AM UTC · Completed 6:46 AM UTC
Commit: bb5c185 · View workflow run →

[fullsend-ai-triage]

Triage Summary

This issue reports that status comments are orphaned in a "Started" state when the fullsend run process is hard-killed (SIGKILL, OOM, segfault), since Go defer statements do not execute on hard termination.

This problem appears to already be addressed in the current codebase. Specifically:

1. ReconcileOrphaned() in internal/statuscomment/statuscomment.go — searches for status comments matching a run's HTML marker that lack the terminal tag, and updates them to an "Interrupted" state.
2. fullsend reconcile-status CLI command in internal/cli/reconcilestatus.go — exposes reconciliation as a subcommand with --repo, --number, --run-id, and --reason flags.
3. Post-job step in action.yml — runs with if: always() (unconditionally, even after cancellation or failure) and calls fullsend reconcile-status, passing the job status to distinguish cancellation from hard termination.

The action.yml step references #2149 in its comments, suggesting this was the tracking issue for the fix.

Recommended next steps

• Verify the reconciliation step is wired into all deployment paths (check dispatch.yml and reusable-dispatch.yml for equivalent coverage).
• If coverage is confirmed, this issue can likely be closed as already resolved.

Proposed verification test

// Verify ReconcileOrphaned finalizes an orphaned "Started" comment:
// 1. Create a mock forge client
// 2. Post a start comment via Notifier.PostStart()
// 3. Without calling PostCompletion, invoke ReconcileOrphaned() with the same runID
// 4. Assert the comment body contains the terminal tag and "Terminated" label
// 5. Call ReconcileOrphaned() again — assert it's a no-op (idempotent)

---

Labels: Bug in status comment lifecycle in the CLI/dispatch layer, with high priority given its user-facing trust impact.

[fullsend-ai-coder]

🤖 Finished Code · ✅ Success · Started 6:48 AM UTC · Completed 6:51 AM UTC
Commit: bb5c185 · View workflow run →