investigate: create-pull-request labels config failure — verify root cause before filing upstream #115
Description
What
Potentially file upstream issue on gh-aw for the create-pull-request labels config failing non-deterministically. Need to verify root cause before filing.
The Error
PR #104 (implementer run 23119170261):
Default labels: aw
Labels: ["aw","aw"]
Created pull request #104: https://github.com/microsasa/cli-tools/pull/104
##[warning]Failed to create pull request: Validation Failed:
{"resource":"Label","code":"unprocessable","field":"data",
"message":"Could not resolve to a node with the global id of 'PR_kwDORibwsM7KwjLj'."}
- https://docs.github.com/rest/issues/labels#add-labels-to-an-issue
PR #106 (same config, same version): Labels applied successfully.
Uncertainty
Two possible root causes:
Theory 1: Handler race condition (gh-aw bug)
The create_pull_request.cjs handler creates the PR, then immediately calls githubClient.rest.issues.addLabels() using pullRequest.number from the create response. The error message references the REST labels endpoint. The PR_kw... node ID in the error could be GitHub's backend failing to resolve the just-created PR — a propagation delay.
Evidence for: The handler code (line 1024) uses issue_number: pullRequest.number, not a node ID. The error references the labels REST endpoint. The failure is non-deterministic (timing-dependent).
Theory 2: Same hallucination bug as thread IDs
The PR_kw... ID might be hallucinated by the agent, similar to how the agent hallucminates PRRT_ thread IDs. But this seems unlikely because: (a) the labels are added by the handler, not the agent, (b) the handler gets the PR number from the create response, not from agent input.
Theory 3: Auto-merge GraphQL mutation failing, not labels
The create_pull_request.cjs wraps create + labels + auto-merge in a single try/catch. The auto-merge step uses pullRequest.node_id in a GraphQL mutation. The PR_kw... ID in the error matches GraphQL node ID format. The catch block logs ANY error as "Failed to create pull request" regardless of which step failed. The labels might have succeeded and it's the auto-merge that failed.
Evidence for: The error message pattern matches GraphQL errors. Auto-merge uses pullRequest.node_id. PR #104 has auto-merge disabled (could mean the mutation failed). But PR #106 has auto-merge enabled (mutation succeeded).
What We Did
Reverted labels: ["aw"] from config in PR #109. Agent instruction-based labeling works reliably.
Before Filing Upstream
Need to determine:
- Which step actually failed — labels or auto-merge? The single try/catch masks this.
- Is the
PR_kw...ID from the handler's create response or from somewhere else? - Could add logging to reproduce locally — but we can't modify gh-aw's handler code.
Draft Issue (if Theory 1 or 3 confirmed)
See conversation history for the full anonymized draft with repro steps.
Related
- bug: labels config on create-pull-request breaks label application #107 — Local bug (labels config broke label application)
- tracking: gh-aw create-pull-request labels config fails to apply labels #108 — Tracking issue for upstream filing
- tracking: upgrade gh-aw MCP server to get real thread IDs for review-responder #114 — Thread ID hallucination (separate but similar error pattern)