[yeti-error] auto-merger:process-pr

[frostyardyeti]

Auto-created by Yeti error reporter
Fingerprint: auto-merger:process-pr
Context: frostyard/snosi#179
Timestamp: 2026-03-27T13:36:28.504Z

Error: gh pr merge 179 --repo frostyard/snosi --squash failed: GraphQL: Pull Request is not mergeable (mergePullRequest)

    at file:///opt/yeti/dist/github.js:309:28
    at ChildProcess.exithandler (node:child_process:424:5)
    at ChildProcess.emit (node:events:519:28)
    at maybeClose (node:internal/child_process:1101:16)
    at ChildProcess._handle.onexit (node:internal/child_process:304:5)
    at Process.callbackTrampoline (node:internal/async_hooks:130:17)

[frostyardyeti]

— Automated by Yeti —

Yeti Error Investigation Report

Investigation Report: [yeti-error] auto-merger:process-pr (Issue #191)

Verified Root Cause

Transient race condition between getPRMergeableState() check and mergePR() call.

The auto-merger at src/jobs/auto-merger.ts:55-66 follows this sequence:

1. Line 55: getPRMergeableState() returns "MERGEABLE" — the guard passes
2. Line 66: mergePR() calls gh pr merge 179 --repo frostyard/snosi --squash
3. GitHub's GraphQL API rejects the merge with "Pull Request is not mergeable (mergePullRequest)"

Between the mergeable-state check and the actual merge attempt, GitHub's internal merge state changed. This is a known GitHub API behavior — the mergeable field can report MERGEABLE while the underlying merge commit computation is still in progress or has been invalidated by a concurrent push to the base branch.

Evidence

1. The PR is now merged — gh pr view 179 --repo frostyard/snosi shows state: MERGED. The error was transient; a subsequent auto-merger cycle (or manual action) successfully merged it.

2. Recurring pattern — This exact same GraphQL error has occurred before:

   • Issue [yeti-error] auto-merger:process-pr #44 (frostyard/updex#46, 2026-03-21) — identical "Pull Request is not mergeable (mergePullRequest)" error
   • Issues [yeti-error] auto-merger:process-pr #109 and [yeti-error] auto-merger:process-pr #113 were a different variant ("base branch policy prohibits the merge") which IS already handled by the catch block at line 68.

3. The catch block only handles one specific error — src/jobs/auto-merger.ts:67-73:

   } catch (err) {
     if (err instanceof Error && err.message.includes("base branch policy prohibits the merge")) {
       log.info(`[auto-merger] ${repo.fullName}#${pr.number} has branch protection, skipping`);
       continue;
     }
     throw err;  // ← the GraphQL "not mergeable" error reaches here and propagates to reportError
   }

   The generic "not mergeable" GraphQL error is not caught, so it propagates to the outer catch at line 87-89, which calls reportError() and creates a [yeti-error] issue.

4. No retry in mergePR() — src/github.ts:896-898 is a simple one-shot call with no retry logic for this specific transient error. The generic gh() wrapper retries on HTTP-level transient errors (500, 502, etc.) but not on GraphQL-level application errors like "Pull Request is not mergeable".

Recommended Fix

Add the transient "not mergeable" GraphQL error to the catch block in src/jobs/auto-merger.ts, treating it as a transient skip (similar to the branch-protection handler). The next polling cycle will re-evaluate and retry:

} catch (err) {
  if (err instanceof Error && err.message.includes("base branch policy prohibits the merge")) {
    log.info(`[auto-merger] ${repo.fullName}#${pr.number} has branch protection, skipping`);
    continue;
  }
  if (err instanceof Error && err.message.includes("Pull Request is not mergeable")) {
    log.warn(`[auto-merger] ${repo.fullName}#${pr.number} transiently not mergeable, will retry next cycle`);
    continue;
  }
  throw err;
}

This is the right approach because:

• The auto-merger runs every 10 minutes, so it will naturally retry
• The PR will be re-evaluated from scratch (mergeable state, checks, etc.) on the next cycle
• It avoids noisy [yeti-error] issues for a condition that resolves itself

[frostyardyeti]

— Automated by Yeti —

Implementation Plan

The issue is well-specified with clear root cause, evidence, and a precise fix. Here's the plan:

Implementation Plan

Summary

Handle the transient "Pull Request is not mergeable" GraphQL error in auto-merger's catch block by logging a warning and continuing to the next PR, instead of propagating to reportError(). The next polling cycle will naturally retry.

Changes

1. src/jobs/auto-merger.ts (lines 67-72)

Add a second catch clause for the generic "not mergeable" GraphQL error, alongside the existing branch-protection handler:

} catch (err) {
  if (err instanceof Error && err.message.includes("base branch policy prohibits the merge")) {
    log.info(`[auto-merger] ${repo.fullName}#${pr.number} has branch protection, skipping`);
    continue;
  }
  if (err instanceof Error && err.message.includes("Pull Request is not mergeable")) {
    log.warn(`[auto-merger] ${repo.fullName}#${pr.number} transiently not mergeable, will retry next cycle`);
    continue;
  }
  throw err;
}

Why: This error is a known GitHub API race condition between the mergeable-state check and the merge call. The PR was subsequently merged on a later cycle — it's transient noise that shouldn't create [yeti-error] issues.

2. src/jobs/auto-merger.test.ts

Add one test case (after the existing "skips PR when branch protection blocks merge" test around line 354):

• "skips PR when transiently not mergeable": Mock mergePR to reject with "Pull Request is not mergeable (mergePullRequest)", verify reportError is NOT called, log.warn IS called with the expected message, notify is NOT called, and the loop continues (no throw).

Update the existing test "still reports non-branch-protection merge errors" (line 356): Verify the test error message ("API error") doesn't match either catch pattern — this test already works correctly since "API error" contains neither substring.

Implementation order

1. Add the catch clause in auto-merger.ts (the production fix)
2. Add the test in auto-merger.test.ts (verify the fix)

Risks and edge cases

• Permanent non-mergeable state: If a PR is genuinely non-mergeable (not transient), this will silently skip it every cycle instead of alerting. This is acceptable because: (a) the getPRMergeableState() check on line 55 already filters CONFLICTING and UNKNOWN states before attempting the merge, and (b) if the state persists, the PR will simply not be merged — no data loss, and the PR remains visible in the queue.
• Substring match specificity: "Pull Request is not mergeable" is broad enough to catch the known GraphQL error but specific enough to not accidentally swallow unrelated errors. The branch-protection variant ("base branch policy prohibits the merge") is caught by the earlier, more specific check.

Testing approach

• Unit test with vitest mocking mergePR rejection. Run with npx vitest run src/jobs/auto-merger.test.ts.

[frostyardyeti]

— Automated by Yeti —

Plan Review

1. Medium: The risk analysis overstates how safe this suppression is. The current precheck only looks at GitHub’s coarse mergeable field via src/github.ts and the job only filters out non-MERGEABLE states in src/jobs/auto-merger.ts. That does not prove every later "Pull Request is not mergeable" failure is a transient race; GitHub can still reject the merge for persistent blockers that are not captured by that three-state check. A blanket catch in the merge block at src/jobs/auto-merger.ts could therefore hide PRs that auto-merger will never be able to merge. The plan should either narrow the condition further or explicitly acknowledge that broader masking risk.

Otherwise the change is small and correctly targeted to auto-merger.ts plus its test file.

[frostyardyeti]

— Automated by Yeti —

Recurrence — 2026-03-31T00:03:03.653Z

Context: frostyard/intuneme#127

Error: gh pr merge 127 --repo frostyard/intuneme --squash failed: GraphQL: Merge already in progress (mergePullRequest)

    at file:///opt/yeti/dist/github.js:309:28
    at ChildProcess.exithandler (node:child_process:424:5)
    at ChildProcess.emit (node:events:519:28)
    at maybeClose (node:internal/child_process:1101:16)
    at ChildProcess._handle.onexit (node:internal/child_process:304:5)
    at Process.callbackTrampoline (node:internal/async_hooks:130:17)

[frostyardyeti]

— Automated by Yeti —

Recurrence — 2026-04-01T15:59:48.101Z

Context: frostyard/snosi#193

Error: gh pr view 193 --repo frostyard/snosi --json mergeable failed: Post "https://api.github.com/graphql": dial tcp 140.82.112.5:443: i/o timeout

    at file:///opt/yeti/dist/github.js:309:28
    at ChildProcess.exithandler (node:child_process:424:5)
    at ChildProcess.emit (node:events:519:28)
    at maybeClose (node:internal/child_process:1101:16)
    at ChildProcess._handle.onexit (node:internal/child_process:304:5)
    at Process.callbackTrampoline (node:internal/async_hooks:130:17)