Survey Repo privacy gate: complete the stderr-surfacing pattern + tempfile cleanup robustness

[marcusrbrown]

Source: PR #3344 Fro Bot review (two non-blocking concerns)
Scope: .github/workflows/survey-repo.yaml

Two related follow-ups left out of PR #3344 to keep the diagnostic surface bounded.

1. Apply the stderr-surfacing pattern to the recheck step

The 🔒 Recheck visibility step (mid-workflow, after the survey agent completes) still uses gh api graphql ... 2>/dev/null. If that step fails after the upstream resolve-step issue is fixed, we'll be back in the same diagnostic blackout we just escaped.

Fix: mirror the resolve step's pattern — capture stderr to a tempfile, dump on failure between --- gh stderr --- markers. Keep marker text identical so any log-parsing tooling can anchor on both occurrences.

2. Robust tempfile cleanup via trap

The current cleanup in the resolve step relies on inline rm -f calls at each exit path. If a future edit adds another early exit (e.g., a new validation check), the tempfile leaks for the life of the runner. Trivial on an ephemeral VM but a real footgun.

Fix: add trap 'rm -f "$gh_stderr"' EXIT immediately after gh_stderr=$(mktemp), drop the inline rm -f calls. Apply to both the resolve and recheck steps once #1 lands.

Acceptance

• Both gh api graphql invocations in survey-repo.yaml surface stderr on failure between identical --- gh stderr --- / --- end gh stderr --- markers.
• Both invocations use trap ... EXIT for tempfile cleanup.
• actionlint clean.

Why deferred

PR #3344 was diagnostic-only with a single concrete goal: surface the real error blocking the bfra-me survey dispatches. Expanding scope to mirror the pattern across all gh-api call sites before the root cause is in hand would have drifted from that goal. Now appropriate as a polish follow-up.

[fro-bot]

Confirmed against main at .github/workflows/survey-repo.yaml. Both gaps are real and exactly as described:

1. Recheck step still swallows stderr. Lines ~207–210 — gh api graphql ... 2>/dev/null followed by a generic Aborting: visibility recheck failed line. If this step ever fails (token rotation, rate limit, transient GraphQL error), we get the same diagnostic blackout that motivated PR #3344. The fix is mechanical: mirror the resolve step's tempfile + --- gh stderr --- marker pattern. Keeping the marker text identical matters so any future log-parsing tooling anchors on a single string across both call sites.

2. Resolve step's cleanup is exit-path-coupled. Lines ~95 and ~100 each carry their own rm -f \"\$gh_stderr\". Works today, but it's the kind of thing the next contributor adding a validation branch will silently regress — a leaked tempfile per dispatch on an ephemeral VM is benign, but the pattern is a footgun. trap 'rm -f \"\$gh_stderr\"' EXIT immediately after mktemp makes the cleanup invariant under all exit paths, including future ones we haven't imagined yet.

Proposed next steps

Single small PR against main that:

1. Refactors the recheck step's gh api graphql to mirror the resolve step: tempfile capture, --- gh stderr --- / --- end gh stderr --- markers on failure, identical wording.
2. Replaces inline rm -f in both steps with trap 'rm -f \"\$gh_stderr\"' EXIT set immediately after each mktemp.
3. Runs actionlint clean.

No behavioral change on the happy path. The only observable diff is what shows up in the job log when GraphQL actually errors — which is the entire point.

I can stage this as a follow-up to #3344 whenever the queue clears. Acceptance criteria from the issue body are unambiguous and the diff is bounded.

---

Run Summary

Field	Value
Event	issues
Repository	fro-bot/.github
Run ID	26172539501
Cache	hit
Session	ses_1b9ff9746fferaS7DCc5D1tg4e