fix(prs): gitea_pr_conflict_resolve says "Conflict Resolution Applied" without confirm when there are no conflicts #24

New issue

Closed

opened 2026-10-24 00:58:40 +00:00 by dsh · 1 comment

dsh commented

2026-10-24 00:58:40 +00:00

Owner

Symptom

gitea_pr_conflict_resolve with no confirm reports Conflict Resolution Applied: No conflicts to resolve. Nothing was applied and no confirmation was given, yet the output claims success. That is misleading for an operator and obscures the dry-run gate.

Repro

gitea_pr_conflict_resolve {owner:"dsh-plugins", repo:"dsh-gitea", pr_number:18}
→ Conflict Resolution Applied: No conflicts to resolve.

No confirm: true was passed; the tool definition says it is dry-run by default and applies only with confirm: true.

Observed vs expected

Observed: "Applied" wording on a no-confirm call.
Expected: a clean-preview response, e.g. Conflict Resolution (dry-run): no conflicts to resolve; nothing to apply. "Applied" only after confirm: true and a real commit.

Root cause

lib/conflict-assistant.js early-returns before the confirmation branch:

if (analysis.clean || !analysis.files || analysis.files.length === 0) {
  return { ok: true, data: { clean: true, summary: 'No conflicts to resolve.' } }
}

lib/handlers/formatters.js only distinguishes data.dryRun; without it, the non-dry-run branch prints Conflict Resolution Applied: ....

Proposed fix

Return dryRun: args.confirm !== true / applied: false in the clean early return, and make the formatter use explicit data.applied (or a clean branch) rather than assuming applied. Tests: no-confirm + clean → dry-run wording; confirm + clean → no-op wording without claiming a commit.

Acceptance: "Applied" never appears unless confirm: true and a resolution commit was created.

Duplicate check

Searched issues for conflict (state all) — only #11/#8 matched the word incidentally; none covers this gate.

Layer

dsh-gitea plugin/tool.

## Symptom `gitea_pr_conflict_resolve` with no `confirm` reports `Conflict Resolution Applied: No conflicts to resolve.` Nothing was applied and no confirmation was given, yet the output claims success. That is misleading for an operator and obscures the dry-run gate. ## Repro ``` gitea_pr_conflict_resolve {owner:"dsh-plugins", repo:"dsh-gitea", pr_number:18} → Conflict Resolution Applied: No conflicts to resolve. ``` No `confirm: true` was passed; the tool definition says it is dry-run by default and applies only with `confirm: true`. ## Observed vs expected - Observed: "Applied" wording on a no-confirm call. - Expected: a clean-preview response, e.g. `Conflict Resolution (dry-run): no conflicts to resolve; nothing to apply.` "Applied" only after `confirm: true` and a real commit. ## Root cause `lib/conflict-assistant.js` early-returns before the confirmation branch: ```js if (analysis.clean || !analysis.files || analysis.files.length === 0) { return { ok: true, data: { clean: true, summary: 'No conflicts to resolve.' } } } ``` `lib/handlers/formatters.js` only distinguishes `data.dryRun`; without it, the non-dry-run branch prints `Conflict Resolution Applied: ...`. ## Proposed fix Return `dryRun: args.confirm !== true` / `applied: false` in the clean early return, and make the formatter use explicit `data.applied` (or a `clean` branch) rather than assuming applied. Tests: no-confirm + clean → dry-run wording; confirm + clean → no-op wording without claiming a commit. Acceptance: "Applied" never appears unless `confirm: true` and a resolution commit was created. ## Duplicate check Searched issues for `conflict` (state all) — only #11/#8 matched the word incidentally; none covers this gate. ## Layer dsh-gitea plugin/tool.

dsh added the

area/forgejo

priority/next

type/bug

labels

2026-10-24 00:58:40 +00:00

dsh referenced this issue

2026-10-24 00:59:54 +00:00

fix(prs): gitea_conflict_analyze reports "0 conflicts" for a nonexistent base branch #37

dsh referenced this issue from a commit

2026-10-24 01:11:14 +00:00

fix(prs): correct merged-PR, conflict and readiness semantics (#23, #24, #37, #38)

dsh referenced this issue

2026-10-24 01:11:19 +00:00

fix(prs): correct merged-PR, conflict and readiness semantics #39

dsh commented

2026-10-24 01:11:36 +00:00

Author

Owner

Fixed in 234cbd4 (PR #39).

The clean early-return in resolveMergeConflicts now carries {clean:true, applied:false, dryRun: !confirm}, and the formatter handles that shape before the applied branch. Live, gitea_pr_conflict_resolve with master/master and no confirm → Conflict Resolution (dry-run): no conflicts to resolve; nothing to apply. “Applied” is reachable only after confirm: true and a real resolution commit.

Tests: test/pr-semantics.test.mjs.

Fixed in `234cbd4` (PR #39). The clean early-return in `resolveMergeConflicts` now carries `{clean:true, applied:false, dryRun: !confirm}`, and the formatter handles that shape before the applied branch. Live, `gitea_pr_conflict_resolve` with `master`/`master` and no `confirm` → `Conflict Resolution (dry-run): no conflicts to resolve; nothing to apply.` “Applied” is reachable only after `confirm: true` and a real resolution commit. Tests: `test/pr-semantics.test.mjs`.

dsh closed this issue

2026-10-24 01:11:42 +00:00