fix(prs): gitea_merge_readiness reports "NOT ready to merge" for an already-merged PR #38

New issue

Closed

opened 2026-10-24 00:59:55 +00:00 by dsh · 1 comment

dsh commented

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

Owner

Symptom

gitea_merge_readiness (and gitea_auto_merge's preview) reports NOT ready to merge for a pull request that is already merged, listing approval/CI checks that no longer matter. Operators cannot tell "blocked" from "already done".

Repro

gitea_pr_get {owner:"dsh-plugins", repo:"dsh-gitea", number:18}
→ Pull request #18 merged.                      (state is merged)

gitea_merge_readiness {owner:"dsh-plugins", repo:"dsh-gitea", number:18}
→ PR #18 Merge Readiness: NOT ready to merge
  Checks:
    - [x] description: Description provided
    - [x] conflicts: No merge conflicts
    - [ ] approval: No approved review
    - [x] ci: No CI checks reported
    - [x] tests: Tests updated
    - [x] migrations: No database migrations

Observed vs expected

Observed: a merged PR is treated as an open PR that fails approval, with no (Merged) marker (the formatter has one, but the handler never sets merged).
Expected: PR #18 is already merged; no merge needed (with the merge commit/date if available), and the check list either omitted or labelled as historical.

Root cause

lib/merge-readiness.js (used by both tools) computes checks from the PR/CI APIs without short-circuiting on pr.merged / pr.merged_at. The formatter (lib/handlers/formatters.js) only appends (Merged) when data.merged is set, which never happens.

Proposed fix

Fetch the PR first; if merged/merged_at is set, return {merged:true, number, mergedAt, url} and let both merge_readiness and auto_merge report "already merged" without running merge checks. Tests for merged/open/blocked PRs.

Acceptance: the Repro says "already merged"; an open blocked PR still lists the failing checks.

Duplicate check

Searched merge/readiness (state all) — no existing issue; #23 is the pr_get rendering bug.

Layer

dsh-gitea plugin/tool.

## Symptom `gitea_merge_readiness` (and `gitea_auto_merge`'s preview) reports `NOT ready to merge` for a pull request that is already merged, listing approval/CI checks that no longer matter. Operators cannot tell "blocked" from "already done". ## Repro ``` gitea_pr_get {owner:"dsh-plugins", repo:"dsh-gitea", number:18} → Pull request #18 merged. (state is merged) gitea_merge_readiness {owner:"dsh-plugins", repo:"dsh-gitea", number:18} → PR #18 Merge Readiness: NOT ready to merge Checks: - [x] description: Description provided - [x] conflicts: No merge conflicts - [ ] approval: No approved review - [x] ci: No CI checks reported - [x] tests: Tests updated - [x] migrations: No database migrations ``` ## Observed vs expected - Observed: a merged PR is treated as an open PR that fails approval, with no `(Merged)` marker (the formatter has one, but the handler never sets `merged`). - Expected: `PR #18 is already merged; no merge needed` (with the merge commit/date if available), and the check list either omitted or labelled as historical. ## Root cause `lib/merge-readiness.js` (used by both tools) computes checks from the PR/CI APIs without short-circuiting on `pr.merged` / `pr.merged_at`. The formatter (`lib/handlers/formatters.js`) only appends `(Merged)` when `data.merged` is set, which never happens. ## Proposed fix Fetch the PR first; if `merged`/`merged_at` is set, return `{merged:true, number, mergedAt, url}` and let both `merge_readiness` and `auto_merge` report "already merged" without running merge checks. Tests for merged/open/blocked PRs. Acceptance: the Repro says "already merged"; an open blocked PR still lists the failing checks. ## Duplicate check Searched `merge`/`readiness` (state all) — no existing issue; #23 is the `pr_get` rendering bug. ## Layer dsh-gitea plugin/tool.

dsh added the

priority/next

area/forgejo

type/task

labels

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

dsh referenced this issue from a commit

2026-10-24 01:11:15 +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:37 +00:00

Author

Owner

Fixed in 234cbd4 (PR #39).

checkMergeReadiness short-circuits on pr.merged/merged_at and returns {merged:true, alreadyMerged:true, mergedAt, url} without running merge checks; autoMergeIfReady returns the same and never calls mergePull for a merged PR. The formatter prints PR #18 is already merged at 2026-10-23T22:56:06Z; no merge needed. (url).

Live: gitea_merge_readiness {number:18} → the already-merged line, no NOT ready, no check list.

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

Fixed in `234cbd4` (PR #39). `checkMergeReadiness` short-circuits on `pr.merged`/`merged_at` and returns `{merged:true, alreadyMerged:true, mergedAt, url}` without running merge checks; `autoMergeIfReady` returns the same and never calls `mergePull` for a merged PR. The formatter prints `PR #18 is already merged at 2026-10-23T22:56:06Z; no merge needed. (url)`. Live: `gitea_merge_readiness {number:18}` → the already-merged line, no `NOT ready`, no check list. Tests: `test/pr-semantics.test.mjs`.

dsh closed this issue

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