Retro post-script should treat 403 comment-posting errors as non-fatal

[guyoron1]

What happened

When the retro post-script receives an HTTP 403 ("Resource not accessible by integration") attempting to post a summary comment on the source PR, the entire workflow is marked as failed — even though the retro agent succeeded and proposal issues were filed.

What should happen

A 403 is a permanent permission error — retrying won't help, and the core deliverables (analysis + proposal issues) were already completed. The post-script should treat 403 and 401 HTTP errors as non-fatal warnings rather than fatal failures.

Proposed change

In post-retro.sh, wrap the summary comment posting step in error handling that treats 403 and 401 HTTP errors as non-fatal:

1. Attempt to post the summary comment to the source PR
2. If 403 or 401, log a warning and continue
3. Exit 0 if the agent succeeded, regardless of whether the comment was posted

---

Mirrored from fullsend-ai#2305

[guyoron1]

/fs-triage

[fullsend-ai-coder]

🤖 Finished Code · ✅ Success · Started 3:31 PM UTC · Completed 3:35 PM UTC
Commit: bb5c185 · View workflow run →

[fullsend-ai-triage]

🤖 Finished Triage · ✅ Success · Started 3:38 PM UTC · Completed 3:40 PM UTC
Commit: bb5c185 · View workflow run →

[fullsend-ai-triage]

Triage Summary

Severity: Medium · Category: Bug

Problem

The post-retro.sh script fails the entire workflow when it receives an HTTP 403 or 401 error posting a summary comment on the originating PR. Because the script uses set -euo pipefail, the unguarded gh api call on lines 127–128 causes an immediate non-zero exit — even though the retro agent succeeded and all proposal issues were already filed.

Root Cause

The gh api call that posts the summary comment has no error handling. A 403 ("Resource not accessible by integration") is a permanent permission error that retrying won't fix, and the core deliverables are already complete at that point.

Recommended Fix

Wrap the gh api call in error handling that captures the exit code. If the error indicates HTTP 403 or 401, log a warning and continue to exit 0. Other errors should remain fatal.

Note: PR #38 is already open and implements this fix.

Proposed Test Case

Scenario: 403 on summary comment posting is non-fatal
  Given the retro agent succeeded and proposals were filed
  When post-retro.sh attempts to post a summary comment
  And the gh api call returns HTTP 403
  Then the script logs a warning
  And exits 0

Scenario: Other HTTP errors remain fatal
  Given the retro agent succeeded
  When post-retro.sh attempts to post a summary comment
  And the gh api call returns HTTP 500
  Then the script exits non-zero

---

Labels: This is a confirmed bug in the dispatch/post-script layer with an open PR, warranting type/bug and pr-open labels.

[fullsend-ai-coder]

🤖 Finished Code · ✅ Success · Started 3:43 PM UTC · Completed 3:45 PM UTC
Commit: bb5c185 · View workflow run →

[fullsend-ai-coder]

An open PR already addresses this issue — skipping automated implementation.

• fix(#36): treat 403/401 comment-posting errors as non-fatal in post-retro #38 by @app/fullsend-ai-coder

To override, comment /fs-code --force on this issue.

_{Posted by fullsend pre-code check}