fix(workflows): safe PR body parsing and idempotent summary comments

[MarkusNeusinger]

Summary

• Fix bot-sync-status PR body parsing that caused shell errors with newlines
• Add idempotency check to prevent duplicate 'Generation Complete' comments

Changes

File	Fix
bot-sync-status.yml	Safely fetch PR body via gh pr view instead of direct variable interpolation
gen-new-plot.yml	Check if summary comment exists before posting (prevents duplicates)

Root Cause

• The PR_BODY variable syntax breaks when the body contains newlines
• The approved label was added 3 times to issue Heatmap: Correlation Matrix [heatmap-correlation] #53, causing 3 duplicate comments

Test plan

• Merge to main
• Create new simple plot request
• Verify sync-status works without errors
• Verify no duplicate comments

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[Copilot]

Pull request overview

This PR fixes two GitHub Actions workflow issues: shell escaping errors when parsing PR bodies containing newlines, and duplicate "Generation Complete" comments caused by multiple workflow runs. The bot-sync-status workflow now uses gh pr view with JSON output for safe PR body retrieval, and the gen-new-plot workflow adds an idempotency check before posting summary comments.

Key Changes

• Fixed PR body parsing in bot-sync-status.yml to prevent shell errors with multi-line content
• Added idempotency check in gen-new-plot.yml to prevent duplicate summary comments
• Removed dead code that built an unused results list

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
.github/workflows/bot-sync-status.yml	Replaced direct PR body variable interpolation with gh pr view --json body to safely handle newlines and special characters
.github/workflows/gen-new-plot.yml	Added check for existing "Generation Complete" comments before posting, and removed unused results collection code

---

You can also share your feedback on Copilot code review for a chance to win a $100 gift card. Take the survey.

[Copilot]

The --jq filter syntax is correct, but the variable assignment could be more robust. If the API call fails, EXISTING could be empty, which would cause the comparison [ "$EXISTING" -gt "0" ] to fail with a "unary operator expected" error.

Consider adding error handling:

EXISTING=$(gh api repos/${{ github.repository }}/issues/${{ github.event.issue.number }}/comments \
  --jq '[.[] | select(.body | startswith("## Generation Complete"))] | length' 2>/dev/null || echo "0")

This ensures EXISTING defaults to "0" if the API call fails, preventing the script from crashing.

Suggested change

	--jq '[.[] | select(.body | startswith("## Generation Complete"))] | length')
	--jq '[.[] | select(.body | startswith("## Generation Complete"))] | length' 2>/dev/null || echo "0")

[Copilot]

[nitpick] The condition if: steps.check_summary.outputs.skip != 'true' will execute the step when skip is anything other than the string 'true', including when it's 'false'. This is correct, but for clarity and consistency with GitHub Actions best practices, consider using a positive check instead:

if: steps.check_summary.outputs.skip == 'false'

This makes the intent more explicit and reduces the risk of unintended execution if the output is unexpectedly empty or malformed.

Suggested change

	if: steps.check_summary.outputs.skip != 'true'
	if: steps.check_summary.outputs.skip == 'false'