fj pr comment: add edit/delete + idempotent --edit-last/--create-if-none #131

New issue

Closed

opened 2026-06-11 00:57:24 +00:00 by stephen · 0 comments

stephen commented

2026-06-11 00:57:24 +00:00

Owner

Task

Bring fj pr comment up to parity with fj issue comment and add the idempotent-upsert flags both sides need:

Add fj pr comment edit <comment-id> and fj pr comment delete <comment-id>, calling the already-present api::issue::edit_comment / delete_comment (src/api/issue.rs:216-232) that the issue side already uses. In Forgejo a PR is an issue, so comment mutation shares the /repos/{owner}/{repo}/issues/comments/{id} path; no new API code. Mirror src/cli/issue_comment.rs.
Add --edit-last and --create-if-none to BOTH fj issue comment and fj pr comment: list the authenticated user's comments on the target, pick the most recent one authored by the token user, and edit it (create when none exists). This is the gh-parity idempotency primitive.

Source: rasterstate/fj#120.

Priority

p2. The single-maintained-status-comment pattern (bot posts "build running", edits it to "build green") is the canonical bot/CI use, and --edit-last/--create-if-none is what collapses the read-modify-write dance into one call. One notch below the p1 scripting-blockers because a working fj api fallback (hand-managed comment id) exists today.

Reason

fj pr comment is write-once: CommentArgs carries only number + body and the handler only posts (src/cli/pr.rs:234, :592); there is no EditComment/DeleteComment verb, unlike the issue side (src/cli/issue.rs:40-44). The write endpoints already exist and already work for PRs, so the gap is purely a missing CLI verb. Even on the issue side, edit/delete exist but there is no idempotency flag, so a bot must view --comments --json, grep its own marker, extract the id, and branch on existence for every update.

Acceptance

fj pr comment edit <id> --body ... and fj pr comment delete <id> work, reusing api::issue::edit_comment / delete_comment.
--edit-last edits the token user's most recent comment on the target; --create-if-none creates one when none exists; both work on fj issue comment and fj pr comment.
--body, --body - (stdin), and $EDITOR fallback all compose with the new flags.
Wiremock coverage in src/client/integration_tests.rs for edit, delete, and the edit-last/create-if-none selection.
cargo fmt --check, cargo clippy --all-targets --all-features -- -D warnings, and cargo test --all pass.

Dependencies

None. Reuses existing comment-mutation endpoints and the src/cli/issue_comment.rs shape. Pairs with rasterstate/fj#124 (-F/--body-file) since maintained status comments are usually generated bodies.

Size

## Task Bring `fj pr comment` up to parity with `fj issue comment` and add the idempotent-upsert flags both sides need: - Add `fj pr comment edit <comment-id>` and `fj pr comment delete <comment-id>`, calling the already-present `api::issue::edit_comment` / `delete_comment` (`src/api/issue.rs:216-232`) that the issue side already uses. In Forgejo a PR is an issue, so comment mutation shares the `/repos/{owner}/{repo}/issues/comments/{id}` path; no new API code. Mirror `src/cli/issue_comment.rs`. - Add `--edit-last` and `--create-if-none` to BOTH `fj issue comment` and `fj pr comment`: list the authenticated user's comments on the target, pick the most recent one authored by the token user, and edit it (create when none exists). This is the gh-parity idempotency primitive. Source: rasterstate/fj#120. ## Priority p2. The single-maintained-status-comment pattern (bot posts "build running", edits it to "build green") is the canonical bot/CI use, and `--edit-last`/`--create-if-none` is what collapses the read-modify-write dance into one call. One notch below the p1 scripting-blockers because a working `fj api` fallback (hand-managed comment id) exists today. ## Reason `fj pr comment` is write-once: `CommentArgs` carries only `number` + `body` and the handler only posts (`src/cli/pr.rs:234`, `:592`); there is no `EditComment`/`DeleteComment` verb, unlike the issue side (`src/cli/issue.rs:40-44`). The write endpoints already exist and already work for PRs, so the gap is purely a missing CLI verb. Even on the issue side, edit/delete exist but there is no idempotency flag, so a bot must `view --comments --json`, grep its own marker, extract the id, and branch on existence for every update. ## Acceptance - [ ] `fj pr comment edit <id> --body ...` and `fj pr comment delete <id>` work, reusing `api::issue::edit_comment` / `delete_comment`. - [ ] `--edit-last` edits the token user's most recent comment on the target; `--create-if-none` creates one when none exists; both work on `fj issue comment` and `fj pr comment`. - [ ] `--body`, `--body -` (stdin), and `$EDITOR` fallback all compose with the new flags. - [ ] Wiremock coverage in `src/client/integration_tests.rs` for edit, delete, and the edit-last/create-if-none selection. - [ ] `cargo fmt --check`, `cargo clippy --all-targets --all-features -- -D warnings`, and `cargo test --all` pass. ## Dependencies None. Reuses existing comment-mutation endpoints and the `src/cli/issue_comment.rs` shape. Pairs with rasterstate/fj#124 (`-F/--body-file`) since maintained status comments are usually generated bodies. ## Size M

stephen added the

backlog

labels

2026-06-11 00:58:25 +00:00

stephen referenced this issue

2026-06-11 00:58:37 +00:00

fj pr comment is write-once: no edit/delete, no --edit-last/--create-if-none, unlike fj issue #120

stephen referenced this issue from a pull request that will close it,

2026-06-11 01:18:30 +00:00

Add edit/delete and idempotent upsert to pr comment #145

stephen closed this issue

2026-06-11 02:07:38 +00:00