Skip to content

fix(platform): merge queue 방출 재투입이 스택 PR 에서 enqueuePullRequest 거부로 실패한다 #2177

Closed

Description

@OnlyReadOneBook

작업 유형

bug — 버그·오동작

주 담당 모듈

platform — Android 앱·CI·빌드·릴리스·저장소 운영

개요

merge-queue-dequeue.yml(pull_request_target: dequeued) 의 handle 잡이 방출된 PR 을 재투입할 때, 그 PR 이 GitHub 네이티브 스택의 일원이면 실패한다. handle-merge-queue-dequeue.mjs 가 재투입 수단으로 GraphQL enqueuePullRequest 만 쓰는데, GitHub 이 스택 PR 에는 이 mutation 을 거부한다.

실측 두 건이다. 둘 다 사유 MERGE_CONFLICT, 실패 job 0, 재투입 횟수 0 으로 requeue 판정까지 간 뒤 mutation 에서 죽었다.

GraphQL 실패: [{"type":"UNPROCESSABLE","path":["enqueuePullRequest"],"message":"This pull request is part of a stack and must be enqueued using the asynchronous merge REST API. For more information, see https://docs.github.com/rest/pulls/pulls#merge-a-pull-request-asynchronously"}]

마커 코멘트("재투입했다")는 mutation 앞에 남기므로, 실패하면 PR 에는 재투입했다는 코멘트만 남고 큐에는 안 들어가며, 다음 방출은 같은 head 의 두 번째로 세어져 give-up 코멘트가 된다. 결국 사람이 gh stack merge 로 다시 넣어야 한다(#2053 은 0919 03:38 에 손으로 재투입했다).

할 일

  1. 스택 일원 판정. GraphQL pullRequest.stack { number } 가 null 이 아니면 스택이다. merge-order-stack-integrity.mjs 가 이미 같은 필드로 스택을 읽는다. live 조회에 이 필드를 얹는다.
  2. 스택이면 REST 비동기 머지 PUT /repos/{owner}/{repo}/pulls/{pull_number}/merge-async 에 merge_action: "merge_queue" 로 재투입하고, 아니면 기존 enqueuePullRequest 경로를 그대로 둔다. 판정표(실패 job 우선, MANUAL·ALREADY_MERGED·MERGE(D) 무동작, 같은 head 당 한 번)는 바꾸지 않는다. MERGE_CONFLICT 사유는 지금처럼 한 번 재투입하고, 다시 빠지면 give-up 코멘트다.
  3. handle-merge-queue-dequeue.test.mjs 에 스택 분기 케이스를 더한다. 스택이면 REST 를 쏘고 GraphQL mutation 은 안 쏜다, 비스택은 종전대로, 쓰기 순서는 마커 코멘트가 먼저.

완료 조건

  • 스택 PR 의 dequeued 이벤트에서 handle 잡이 초록으로 끝나고 PR 이 큐에 들어간다(mergeQueueEntry 가 생긴다)
  • 비스택 PR 의 재투입 경로와 판정표는 그대로다
  • node --test .github/scripts/handle-merge-queue-dequeue.test.mjs 가 통과한다
  • 저장소 설정과 룰셋은 바꾸지 않는다

자식 이슈

No response

참고

Activity

  1. added
    bugSomething isn't working
    area:platformCI·빌드·릴리스·저장소 운영 영역
    on Sep 26, 2026
  2. github-actions commented on Sep 26, 2026

    @github-actions
    Contributor

    bug 이슈는 사이드바 Fields > Priority 로 심각도를 지정해야 합니다. 판정 기준:

    • Urgent: 치명 — 크래시·데이터 소실·보안 무력화·핵심 경로 차단·가짜 성공
    • High: 심각 — 실패·틀린 값의 정상 위장, 핵심 기능 무동작
    • Medium: 불편 — 우회로가 있는 오동작·틀린 표시, 핵심 흐름은 유지
    • Low: 경미 — 문구·정렬·마감 품질 흠, 기능 영향 없음

    값이 비어 있어도 이슈를 닫지는 않습니다. 이 안내는 이슈당 한 번만 답니다.

  3. added
    pr-open이 이슈를 구현하는 PR 이 열려 있다 — base 가 기본 브랜치가 아니어도 드러낸다
    on Sep 27, 2026
  4. removed
    pr-open이 이슈를 구현하는 PR 이 열려 있다 — base 가 기본 브랜치가 아니어도 드러낸다
    on Oct 4, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

area:platformCI·빌드·릴리스·저장소 운영 영역bugSomething isn't working

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions