Skip to content

feat(#6966)!: replace stale findings on ok via issues post-comment --only-if-exists - #7917

Merged
waynesun09 merged 4 commits into
mainfrom
agent-6966-only-if-exists
Oct 1, 2026
Merged

waynesun09 merged 4 commits into
mainfrom
agent-6966-only-if-exists

Conversation

@waynesun09

@waynesun09 waynesun09 commented Oct 1, 2026 •

Copy link
Copy Markdown
Member

What

  • New flag fullsend issues post-comment --only-if-exists: updates the poster's own earlier marker comment and never creates one. The GitHub/GitLab and Jira paths in internal/cli honour it after feat(cli)!: verify the comment author before issues post-comment edits #7916's author check, so a comment someone else planted with the marker is never the target. internal/sticky is unchanged.
  • Generated ok path: on status: ok, the post-script that fullsend agent new generates now sends the all-clear through --only-if-exists --keep-history=false. The all-clear replaces the earlier findings in place, so repeated clean runs don't stack identical history.

Why

On status: ok the generated post-script posted nothing. The trigger fires again on later pushes, so a findings comment from an earlier push stayed on the pull request after the author fixed the problem. The fix needs to update that comment without creating one on a clean first run, which is what the new flag does.

The runner's fullsend is pinned by the repository's fullsend-ref, not by the CLI that generated the script. So the script detects the flag from post-comment --help instead of assuming it, and keeps the old "post nothing" behaviour on an older CLI. A fullsend that is missing or whose --help fails is a broken runner, not an older CLI, so the run fails. A failed post fails the run. A dry run calls nothing and says it did not check for an earlier comment. The ok path now runs after ISSUE_URL validation, so an ok result with a non-GitHub ISSUE_URL is rejected like any other.

BREAKING CHANGE

A post-script regenerated with fullsend agent new now fails the run on a status: ok result in any of these cases:

  • fullsend is missing, or fullsend issues post-comment --help fails;
  • the posting identity can't be resolved (see feat(cli)!: verify the comment author before issues post-comment edits #7916);
  • the comment lookup or the post itself fails;
  • the work item's ISSUE_URL is not a GitHub issue or pull request URL. The ok path now runs after that check, so an ok result with such a URL is rejected like any other, where it used to exit 0.

Before, the ok branch always exited 0. Existing generated scripts are plain files and keep their behaviour until regenerated.

Migrating: when you regenerate, make sure fullsend is on the post-script's PATH, and that the token it posts with can read its own identity (see #7916). A run that fails on a transient identity or API error can simply be rerun.

Release note

Generated post-scripts now call fullsend issues post-comment on an ok result, so fullsend must be on PATH for the ok path, and a broken fullsend --help fails the run. Scripts generated before this change keep their behaviour until regenerated.

Tests

  • CLI: creates nothing with no earlier comment, and replaces the poster's own earlier findings. With --keep-history=false, three clean runs leave exactly one all-clear and no "Previous run" block. Under --only-if-exists it ignores a planted marker comment (GitHub look-alike logins; on Jira, a marker property set by another account), and skips a planted comment listed before the poster's own.
  • Generated script: an ok result with a non-GitHub ISSUE_URL fails like any other. Stubbed fullsend binaries cover five cases:
    • one that knows the flag receives --only-if-exists and --keep-history=false;
    • one that doesn't is never asked to post;
    • one whose post fails makes the run fail;
    • one whose --help fails makes the run fail;
    • under dry run, the stub is never called.
  • Mutations: each of these fails a test: dropping --only-if-exists from the template call, dropping the "nothing to post" branch on the tracker or Jira path, dropping the dry-run guard, swallowing a failed post with || true, treating a failed --help as an older CLI, dropping --keep-history=false, and not passing the flag through.
  • Goldens and docs: the goldens are regenerated, and the diff is the ok-path hunks only. docs/guides/user/issues-commands.md and docs/guides/dev/cli-internals.md list the flag.
go test -race ./internal/agentnew/ ./internal/cli/ ./internal/sticky/

Split out of #7243. Part of #6966.

🤖 Generated with Claude Code

@qodo-code-review

Copy link
Copy Markdown

PR Summary by Qodo

Clear stale agent findings with update-only issue comments

🐞 Bug fix ✨ Enhancement 🧪 Tests 🕐 20-40 Minutes

Grey Divider

AI Description

• Add update-only issue comments so all-clear results replace earlier findings without creating new
 comments.
• Require an exact author match before updating marked comments on forge trackers or Jira.
• Keep generated scripts compatible with older CLIs and cover posting, dry runs, and failure paths.
Diagram

graph TD
  A["Agent result"] --> B["Post script"] --> C{"Valid GitHub URL?"}
  C -- "yes" --> D{"Flag supported?"}
  D -- "yes" --> E["Post comment"] --> F["Tracker backend"] --> G["Update owned comment"]
  C -- "no: error" --> H["Exit without post"]
  D -- "no" --> H
  B -- "dry run" --> H
  F -- "no match" --> H
Loading
High-Level Assessment

Using the existing issues post-comment lifecycle is the right approach: it centralizes author verification and marker matching for forge trackers and Jira. Reimplementing comment lookup in the generated shell script would duplicate that logic and its security checks.

Files changed (9) +507 / -75

Enhancement (2) +35 / -15
issues.goAdd update-only issue comment posting +29/-15

Add update-only issue comment posting

• Exposes --only-if-exists and passes it into sticky configuration. Forge-tracker and Jira posting paths now skip creation when no marked comment by the verified posting identity exists.

internal/cli/issues.go

sticky.goCarry update-only intent in sticky configuration +6/-0

Carry update-only intent in sticky configuration

• Adds OnlyIfExists for the issues CLI posting paths and clarifies that sticky.Post itself does not consume it.

internal/sticky/sticky.go

Bug fix (1) +38 / -7
post.sh.tmplReplace earlier findings on all-clear runs +38/-7

Replace earlier findings on all-clear runs

• Validates ISSUE_URL before handling an all-clear result, then uses update-only posting when the runner CLI supports it. Dry runs and older CLIs post nothing; a failed post fails the script.

internal/agentnew/templates/post.sh.tmpl

Tests (4) +427 / -49
postscript_exec_test.goExercise generated all-clear posting +147/-0

Exercise generated all-clear posting

• Adds execution tests for dry runs, supported and older CLIs, and failed update-only posts.

internal/agentnew/postscript_exec_test.go

triage.txtRefresh generated triage script fixture +38/-7

Refresh generated triage script fixture

• Updates the golden script to reflect all-clear posting, capability detection, and URL validation order.

internal/agentnew/testdata/golden/triage.txt

validation-loop.txtRefresh validation-loop script fixture +38/-7

Refresh validation-loop script fixture

• Updates the golden script with the same all-clear and older-CLI behavior.

internal/agentnew/testdata/golden/validation-loop.txt

issues_test.goCover update-only posting and author safety +204/-35

Cover update-only posting and author safety

• Tests creation suppression and replacement on forge trackers and Jira. Extends identity-failure and planted-marker coverage to the update-only path.

internal/cli/issues_test.go

Documentation (2) +7 / -4
cli-internals.mdList the new post-comment flag +1/-0

List the new post-comment flag

• Adds --only-if-exists to the CLI command reference.

docs/guides/dev/cli-internals.md

issues-commands.mdExplain update-only comment behavior +6/-4

Explain update-only comment behavior

• Documents all-clear usage, history behavior, exact author matching, and the failure when the posting identity cannot be resolved.

docs/guides/user/issues-commands.md

@qodo-code-review

qodo-code-review Bot commented Oct 1, 2026 •

Copy link
Copy Markdown

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

Grey Divider


Remediation recommended

1. Failed help checks leave stale findings ✓ Resolved
Description
The generated post-script treats any failure of fullsend issues post-comment --help as proof that
--only-if-exists is unavailable, then exits successfully. If the runner cannot execute the CLI or
its help command fails for another reason, an earlier findings comment remains unchanged and the run
reports its post-script as completed.
Code

internal/agentnew/templates/post.sh.tmpl[R136-139]

+  if ! fullsend issues post-comment --help 2>&1 | grep -- '--only-if-exists' >/dev/null; then
+    echo "post-__AGENT_NAME__: status=ok, nothing to post (this fullsend has no --only-if-exists; an earlier findings comment, if any, stays until a later run with findings)" >&2
+    exit 0
+  fi
Relevance

●●● Strong

Failed capability checks are indistinguishable from unsupported flags, masking runner failures and
leaving stale findings.

PR-#7817

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The new negated pipeline routes both a missing flag and a failed help command to the same successful
exit 0. The runner marks a zero-exit post-script as completed, so it cannot surface that the
all-clear update was skipped.

internal/agentnew/templates/post.sh.tmpl[130-148]
internal/cli/run.go[1881-1893]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The generated all-clear path silently succeeds when the CLI help probe fails, leaving an earlier findings comment unchanged.
## Fix Focus Areas
- internal/agentnew/templates/post.sh.tmpl[130-139]
- internal/agentnew/postscript_exec_test.go[212-251]
## Recommended Fix
Capture the help command's exit status separately from searching its complete output. Fail the script when help itself fails; retain the no-post fallback only when help succeeds but does not list `--only-if-exists`. Add a stubbed-CLI test for a failing help command.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


2. Repeated clean runs stack identical history ✓ Resolved
Description
The ok path calls post-comment --only-if-exists without --keep-history=false, and after the first
all-clear the bot's marked comment still exists. Every later ok run therefore calls UpdateComment,
and BuildUpdatedBody pushes the identical previous all-clear into a new 'Previous run' block. Each
synchronize push writes to the API, and the original findings eventually drop off at the size cap.
Code

internal/agentnew/templates/post.sh.tmpl[R145-148]

+        --marker "${MARKER}" \
+        --only-if-exists \
+        --result -
+  exit 0
Relevance

●●● Strong

Recent sticky-comment precedent accepts disabling history to prevent noisy repeated updates and
comment growth.

PR-#6930

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
BuildUpdatedBody always adds the current old content as 'Previous run' with no equality check. The
update branch in postTrackerStickyComment runs whenever existing != nil, whatever OnlyIfExists is
set to. The template uses the default keep-history=true.

internal/sticky/sticky.go[195-205]
internal/cli/issues.go[442-461]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
On every ok run after the first all-clear, the existing marked comment is found and updated. BuildUpdatedBody prepends the identical previous all-clear as a new history entry, so history fills with duplicates and an API write happens on every push.

## Fix Focus Areas
- internal/agentnew/templates/post.sh.tmpl[140-148]
- internal/cli/issues.go[442-461]

## Recommended Fix
Either:
- in postTrackerStickyComment and postJiraStickyComment, when OnlyIfExists is set and the existing body (marker stripped, history blocks removed) already equals the new body, return without updating; or
- pass --keep-history=false on the ok call in the template.

Regenerate the golden files and add a test that runs the all-clear twice.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Informational

3. A shared option is silently ignored by one poster ✓ Resolved
Description
The OnlyIfExists field was added to the shared sticky.Config, but sticky.Post never reads it and
still creates a comment when none exists. Any caller of sticky.Post that sets the field gets a new
comment instead of a no-op, and only a doc comment warns about this.
Code

internal/sticky/sticky.go[R24-29]

+	// OnlyIfExists updates an existing marked comment but never creates one:
+	// a post-script uses it on an all-clear result so an earlier findings
+	// comment is replaced while a clean first run stays silent. It is
+	// honoured by `fullsend issues post-comment` (internal/cli), which also
+	// verifies the comment author; Post here does not read it.
+	OnlyIfExists bool
Relevance

●●● Strong

The shared option is ineffective through sticky.Post, creating surprising behavior for callers using
the common configuration.

PR-#6930

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
Post goes straight to CreateIssueComment when no existing comment is found and never checks
OnlyIfExists.

internal/sticky/sticky.go[80-93]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
sticky.Config.OnlyIfExists is ignored by sticky.Post, which still creates a comment when none exists.

## Fix Focus Areas
- internal/sticky/sticky.go[24-29]
- internal/sticky/sticky.go[80-93]

## Recommended Fix
Before the create branch in sticky.Post, add: if cfg.OnlyIfExists, log that there is nothing to post and return "", nil. Alternatively, move the flag out of sticky.Config into a CLI-local parameter.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Grey Divider

Context sources
✅ Compliance rules (platform): 72 rules
✅ Cross-repo context — repo relationships
  Explored: repo: fullsend-ai/agents (sha: 3af27dde) — View relationship
Review mode: 🧠 Deep: This changes comment-posting behavior across CLI, GitHub/Jira paths, generated shell templates, compatibility detection, identity checks, and extensive tests, creating many independent opportunities for subtle regressions.

Grey Divider

Tip of the day
💡 Did you know, you can keep summaries lean with Findings visible per group, which tucks the rest behind a View link

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

Grey Divider

Qodo Logo

Comment thread internal/agentnew/templates/post.sh.tmpl Outdated
Comment thread internal/agentnew/templates/post.sh.tmpl
Comment thread internal/sticky/sticky.go Outdated
@fullsend-ai-review

fullsend-ai-review Bot commented Oct 1, 2026 •

Copy link
Copy Markdown

🤖 Finished Review · ✅ Success · Started 2:52 PM UTC · Completed 3:31 PM UTC

Commit: 27d1971 · View workflow run →

Runtime: pi · Model: sonnet → claude-sonnet-5 · Effort: high · Cost: $3.17

@github-actions

github-actions Bot commented Oct 1, 2026 •

Copy link
Copy Markdown

Site preview

Preview: https://654f85c2-site.fullsend-ai.workers.dev

Commit: 93f9b47d0b699b690f54a699fe942fcc0b0bf4f6

@codecov

codecov Bot commented Oct 1, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

@fullsend-ai-review fullsend-ai-review Bot added the risk/moderate PR risk: moderate label Oct 1, 2026
@fullsend-ai-review

fullsend-ai-review Bot commented Oct 1, 2026 •

Copy link
Copy Markdown

Risk Assessment: moderate (2/5)

Details

Moderate risk for an additive, opt-in CLI flag and template update with comprehensive tests and no protected path changes, balanced against elevated git churn and regression history in modified files.

Previous run

Risk Assessment: moderate (2/5)

Details

Moderate risk for an additive, opt-in CLI flag and template update with comprehensive tests and no protected path changes, balanced against elevated git churn and regression history in modified files.

Previous run (2)

Risk Assessment: moderate (2/5)

Details

Moderate risk for an additive, opt-in CLI flag and template update with comprehensive tests and no protected path changes, balanced against elevated git churn and regression history in modified files.

Previous run (3)

Risk Assessment: moderate (2/5)

Details

Moderate risk: focused addition of an opt-in CLI flag with strong test coverage and no protected path changes, offset by moderate churn and coupling in touched CLI and agent generator files.

@fullsend-ai-review

fullsend-ai-review Bot commented Oct 1, 2026 •

Copy link
Copy Markdown

Looks good to me

Previous run

Review

Findings

Medium

  • [breaking-cli] internal/agentnew/templates/post.sh.tmpl:157 — Regenerated post-scripts can now fail on a live status: ok result when identity resolution, comment lookup, or posting fails. Previously, reaching the ok branch exited successfully without those operations. Identity resolution precedes the existing-comment check, so even a clean first run can encounter the new failure mode. COMMITS.md requires breaking behavior changes to carry ! in both PR titles and commit subjects, plus a BREAKING CHANGE: trailer; the current PR title and behavior-changing commits lack these markers. The release-note paragraph explains the change but does not replace the required markers.
    Remediation: Add ! to the PR title and behavior-changing commit subjects, and add a BREAKING CHANGE: trailer describing the new failure conditions for regenerated post-scripts. Existing scripts remain unchanged until regenerated.

Next steps:

  • /fs-fix — agent addresses review findings automatically
  • /fs-fix <your instruction> — agent fixes with your specific guidance
  • Push commits directly — review re-runs automatically on push
  • /fs-fix-stop — disable automatic fix runs for this PR
Previous run (2)

Looks good to me


Labels: Adds a user-facing CLI option and updates custom-agent generated post-scripts.

Previous run (3)

Review

Findings

Low

  • [test-patterns] internal/cli/issues_test.go:65 — TestNewIssuesPostCommentCmd_DefaultFlags asserts cobra defaults for --result and --dry-run but was not updated to assert registration and default value of the new --only-if-exists flag (should be false). The behavioral tests elsewhere construct issuesPostCommentConfig directly with an explicit bool, so none of them pin the cobra flag's own default.
    Remediation: Add an assertion in TestNewIssuesPostCommentCmd_DefaultFlags that cmd.Flags().Lookup("only-if-exists") is not nil and its DefValue is "false".

Next steps:

  • /fs-fix — agent addresses review findings automatically
  • /fs-fix <your instruction> — agent fixes with your specific guidance
  • Push commits directly — review re-runs automatically on push
  • /fs-fix-stop — disable automatic fix runs for this PR
Previous run (4)

Review

Findings

High

  • [sub-agent-failure] N/A — The correctness sub-agent did not return findings: it timed out after 900s on this review run, as it also did on the prior review (two reviews in a row now). Correctness review (logic errors, edge cases, API-contract violations, test adequacy for the --only-if-exists plumbing and the generated post.sh.tmpl ok-path rework) was not completed for this PR.
  • [sub-agent-failure] N/A — The security sub-agent did not return findings: it timed out after 900s on this review run, as it also did on the prior review. Security review was not completed, including whether --only-if-exists correctly routes through the PR feat(cli)!: verify the comment author before issues post-comment edits #7916 author-identity check on both the GitHub/GitLab and Jira tracker paths, and whether the degradation path on an older fullsend binary (detected via --help text sniffing) fails open or closed.
  • [sub-agent-failure] N/A — The adversarial challenger pass also timed out after 900s before it could adjudicate the medium findings below (verify whether the two post.sh.tmpl behavior-change findings are already disclosed/intentional/tested, and whether the docs/cli/agent.md example is fully or only partially stale). The findings below are the raw, unchallenged sub-agent output.

Medium

  • [stale-example-output] docs/cli/agent.md:342 — The "Running it" walkthrough's sample output for a successful ok run shows post-link-check: status=ok, nothing to post. That example is attributed in the surrounding prose to a pre-existing reference agent (fullsend-ai/agents examples/link-check/), whose already-generated post-script is a static artifact not automatically re-rendered by this PR's template change — so this specific example may still be literally accurate for that one agent. However, a user who runs fullsend agent new today and follows this doc's walkthrough will see different output on a clean ok run after this PR (a call into fullsend issues post-comment --only-if-exists rather than a bare "nothing to post" message), so the doc may mislead new readers about what to expect. Not independently verified for severity nuance (challenger timed out before adjudicating).
    Remediation: Confirm whether this example reflects a frozen, already-generated agent (doc stays as-is, perhaps with a note) or the current agent new generated behavior (update the sample output to match the new post-script logic).
  • [generated-script-contract] internal/agentnew/templates/post.sh.tmpl:115 — The status == "ok" early-exit moved from before the ISSUE_URL regex validation to after it. Previously an ok result exited 0 regardless of ISSUE_URL shape; now an ok result with a malformed/non-GitHub ISSUE_URL fails the run (exit 1) instead of succeeding silently. Note: the PR body explicitly states this is intentional ("The ok path now runs after ISSUE_URL validation, so an ok result with a non-GitHub ISSUE_URL is rejected like any other"), so this may be disclosed, intentional behavior rather than an oversight — not independently confirmed as test-covered since the challenger pass that was meant to verify this against postscript_exec_test.go timed out.
    Remediation: Confirm this is intentional (it appears to be, per the PR body) and that it is covered by a test pinning the new failure behavior for a malformed ISSUE_URL on the ok path specifically; if not already covered, add one.
  • [generated-script-contract] internal/agentnew/templates/post.sh.tmpl:126 — The ok path now unconditionally invokes fullsend issues post-comment --help (outside dry-run), introducing a new hard dependency on the fullsend binary being resolvable for an outcome that previously needed no external binary at all. The PR body discloses this ("A fullsend that is missing or whose --help fails is a broken runner... so the run fails") and TestGeneratedPostScriptOkFailsWhenFullsendHelpFails appears to pin it, but this was not independently re-verified since the challenger pass timed out before confirming test coverage and the retroactive-impact question (whether already-generated, already-deployed post-<agent>.sh scripts in other repos are affected, or only newly-generated ones).
    Remediation: Call out the new unconditional fullsend-on-PATH requirement for the ok path in release notes so harness operators relying on older generated scripts are not surprised when they regenerate.

Low

  • [sub-agent-failure] N/A — The challenger sub-agent did not return findings: it timed out after 900s. Using the pre-challenger finding set above without adversarial adjudication, false-positive removal, or cross-dimension deduplication.

Next steps:

  • /fs-fix — agent addresses review findings automatically
  • /fs-fix <your instruction> — agent fixes with your specific guidance
  • Push commits directly — review re-runs automatically on push
  • /fs-fix-stop — disable automatic fix runs for this PR
Previous run (5)

Review

Findings

High

  • [sub-agent-failure] N/A - The correctness sub-agent did not return findings: it timed out after 900s on two consecutive dispatch attempts. Correctness review (logic errors, edge cases, API-contract violations, test adequacy) was not completed for this PR.
  • [sub-agent-failure] N/A - The security sub-agent did not return findings: it timed out after 900s on two consecutive dispatch attempts. Security review was not completed, including whether --only-if-exists correctly routes through the PR feat(cli)!: verify the comment author before issues post-comment edits #7916 author-identity check on both the GitHub/GitLab and Jira tracker paths, and whether the degradation path on an older fullsend binary fails open or closed.

Medium

  • [api-shape] internal/sticky/sticky.go:29 - OnlyIfExists is added to sticky.Config with a doc comment stating that sticky.Post ignores it and that only fullsend issues post-comment (internal/cli) honours it. This is an abstraction leak: a lower-level library's config struct carries a field explicitly documented as non-functional within its own package's primary entry point.
    Remediation: Either have sticky.Post honour cfg.OnlyIfExists (mirroring the check already added in postTrackerStickyComment/postJiraStickyComment), or keep onlyIfExists scoped to internal/cli rather than adding an unused field to sticky.Config.

Low

  • [cli-version-compatibility] internal/agentnew/templates/post.sh.tmpl:139 - The generated post-script detects --only-if-exists support by grepping the literal flag name out of fullsend issues post-comment --help text rather than a stable, machine-readable capability signal. A future change to how flags render in --help output could silently cause the safe-degradation branch ("nothing to post") to trigger even on a CLI that does support the flag, with no visible error.
    Remediation: Consider a more robust detection primitive long-term (e.g., probing the exit code directly, or a dedicated capabilities command), and document the "--help text sniffing" convention for future contributors adding similar generated-template/CLI compatibility checks.

Next steps:

  • /fs-fix — agent addresses review findings automatically
  • /fs-fix <your instruction> — agent fixes with your specific guidance
  • Push commits directly — review re-runs automatically on push
  • /fs-fix-stop — disable automatic fix runs for this PR

fullsend-ai-review[bot]

This comment was marked as outdated.

@fullsend-ai-review

fullsend-ai-review Bot commented Oct 1, 2026 •

Copy link
Copy Markdown

🤖 Finished Review · ✅ Success · Started 3:53 PM UTC · Completed 4:35 PM UTC

Commit: c9231c7 · View workflow run →

Runtime: pi · Model: sonnet → claude-sonnet-5 · Effort: high · Cost: $3.89

fullsend-ai-review[bot]

This comment was marked as outdated.

@fullsend-ai-review

fullsend-ai-review Bot commented Oct 1, 2026 •

Copy link
Copy Markdown

🤖 Finished Review · ✅ Success · Started 4:41 PM UTC · Completed 5:05 PM UTC

Commit: 2863b89 · View workflow run →

Runtime: pi · Model: sonnet → claude-sonnet-5 · Effort: high · Cost: $7.25

fullsend-ai-review[bot]

This comment was marked as outdated.

fullsend-ai-review[bot]

This comment was marked as outdated.

@fullsend-ai-review

fullsend-ai-review Bot commented Oct 1, 2026 •

Copy link
Copy Markdown

🤖 Review · ⚠️ Cancelled · Started 5:12 PM UTC · Ended 5:14 PM UTC

Commit: c08dd15 · View workflow run →

Comment thread internal/agentnew/templates/post.sh.tmpl
@fullsend-ai-review

fullsend-ai-review Bot commented Oct 1, 2026 •

Copy link
Copy Markdown

🤖 Finished Review · ✅ Success · Started 8:45 PM UTC · Completed 9:07 PM UTC

Commit: 6e23a22 · View workflow run →

Runtime: pi · Model: openai/gpt-6.1-sol → gpt-6.1-sol · Effort: high · Cost: $3.26

fullsend-ai-review[bot]

This comment was marked as outdated.

@fullsend-ai-review
fullsend-ai-review Bot dismissed their stale review October 1, 2026 21:07

Superseded by updated review

@fullsend-ai-review fullsend-ai-review Bot removed the ready-for-merge All reviewers approved — ready to merge label Oct 1, 2026
…only-if-exists

On status ok the generated post-script posted nothing, so a findings
comment from an earlier push stayed on the pull request after a later
push fixed the problem (the trigger fires again on synchronize).

Add `issues post-comment --only-if-exists`: update the poster's own
earlier marker comment, never create one. sticky.Config.OnlyIfExists
carries it to the GitHub/GitLab and Jira paths, which honour it after the
author check, so a comment someone else planted with the marker is never
the target. sticky.Post does not read it.

The generated ok path now pipes the all-clear through it. The runner's
fullsend is pinned by fullsend-ref, not by the CLI that generated the
script, so the script detects the flag from --help (reading the whole
text, no grep -q, so an early exit cannot SIGPIPE it) and keeps the old
"post nothing" on an older CLI. A failed post fails the run. Dry run
calls nothing and says it did not check for an earlier comment. The ok
path now runs after ISSUE_URL validation, so an ok result with a
non-GitHub ISSUE_URL is rejected like any other.

Tests: the flag on the forge-client and Jira paths (including a marker
property planted by another account), and the generated ok path with
stubbed fullsend binaries that do and do not know the flag, that fail
the post, and that must not be called under dry run. Goldens regenerated;
docs list the flag.

BREAKING CHANGE: a regenerated post-script now fails the run on a status ok
 result when fullsend is missing, its --help fails, the posting identity
 cannot be resolved, or the post fails; previously the ok branch always
 exited 0. Existing generated scripts are unchanged until regenerated.
Assisted-by: Claude (fix), Claude (review)
Signed-off-by: Wayne Sun <gsun@redhat.com>
…-if-exists in cli

- The generated ok path now fails when `fullsend issues post-comment
  --help` itself fails (fullsend missing or broken): that is a broken
  runner, not an older CLI. Only a working CLI without the flag still
  posts nothing. Capturing the help text also removes the grep pipeline.
- The ok call passes --keep-history=false, so the all-clear replaces the
  comment in place and repeated clean runs do not stack identical
  "Previous run" blocks.
- onlyIfExists is a parameter of the CLI's post functions instead of a
  sticky.Config field that sticky.Post never read; internal/sticky is
  unchanged.

BREAKING CHANGE: a regenerated post-script now fails the run on a status ok
 result when fullsend is missing, its --help fails, the posting identity
 cannot be resolved, or the post fails; previously the ok branch always
 exited 0. Existing generated scripts are unchanged until regenerated.
Assisted-by: Claude (fix), Claude (review)
Signed-off-by: Wayne Sun <gsun@redhat.com>
The ok path runs after the ISSUE_URL check, so an ok result is validated
like any other. Moving the ok block back above the check fails the test.

Assisted-by: Claude (fix), Claude (review)
Signed-off-by: Wayne Sun <gsun@redhat.com>
Assisted-by: Claude (fix), Claude (review)
Signed-off-by: Wayne Sun <gsun@redhat.com>
@waynesun09
waynesun09 force-pushed the agent-6966-only-if-exists branch from 6e23a22 to 93f9b47 Compare October 1, 2026 21:17
@waynesun09 waynesun09 changed the title feat(#6966): replace stale findings on ok via issues post-comment --only-if-exists feat(#6966)!: replace stale findings on ok via issues post-comment --only-if-exists Oct 1, 2026
@fullsend-ai-review

fullsend-ai-review Bot commented Oct 1, 2026 •

Copy link
Copy Markdown

🤖 Finished Review · ✅ Success · Started 9:18 PM UTC · Completed 9:29 PM UTC

Commit: 93f9b47 · View workflow run →

Runtime: pi · Model: openai/gpt-6.1-sol → gpt-6.1-sol · Effort: high · Cost: $2.52

@fullsend-ai-review fullsend-ai-review Bot added the ready-for-merge All reviewers approved — ready to merge label Oct 1, 2026

@ggallen ggallen left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed the current top commit. I found no additional actionable issues. The update-only flow is correctly author-scoped, avoids creating comments on clean first runs, preserves older-runner compatibility, fails visibly on runner/update errors, and has appropriate GitHub/GitLab/Jira and repeated-run coverage.

@waynesun09
waynesun09 added this pull request to the merge queue Oct 1, 2026
Merged via the queue into main with commit 1437764 Oct 1, 2026
64 checks passed
@waynesun09
waynesun09 deleted the agent-6966-only-if-exists branch October 1, 2026 22:24

This branch was successfully deployed

1 active and 1 inactive deployments
site-preview — 93f9b47d Deployed Oct 1, 2026 by github-actions[bot]
dev — 93f9b47d Deployed Oct 1, 2026 by waynesun09 via behaviour #14906
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

component/harness Agent harness, config, and skills loading ready-for-merge All reviewers approved — ready to merge risk/moderate PR risk: moderate type/feature New capability request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants