Summary
When creating PRs through gh-aw, labels can be applied late enough that pull_request_target workflows triggered by the initial opened event see the PR as unlabeled and fail required-label checks. This has happened twice recently in elastic/docs-actions.
This does not look like the label-checking action misreading the final PR state. In both cases, the failing run evaluated the PR before the release label was present, and a later run passed once the label existed.
Evidence
Repository: https://github.com/elastic/docs-actions
PR: elastic/docs-actions#117
-
PR created at 2026-04-28T07:00:46Z.
-
Initial required-labels run failed: https://github.com/elastic/docs-actions/actions/runs/25038719070
-
The job intentionally waited 30 seconds on opened, then checked labels at about 2026-04-28T07:01:25Z.
-
Failure message:
Label error. Requires exactly 1 of: automation, breaking, bug, changelog:skip, chore, ci, dependencies, documentation, enhancement, feature, fix. Found:
-
Timeline shows the enhancement label was added at 2026-04-28T07:01:36Z, after the failed check had already completed.
-
A later required-labels run passed: https://github.com/elastic/docs-actions/actions/runs/25038751464
PR: elastic/docs-actions#118
-
PR created at 2026-04-28T07:12:59Z.
-
Initial required-labels run failed: https://github.com/elastic/docs-actions/actions/runs/25039200942
-
The job waited 30 seconds on opened, then checked labels at about 2026-04-28T07:13:40Z.
-
Failure message:
Label error. Requires exactly 1 of: automation, breaking, bug, changelog:skip, chore, ci, dependencies, documentation, enhancement, feature, fix. Found:
-
Timeline shows the fix label was added at 2026-04-28T07:17:41Z.
-
A later required-labels run passed: https://github.com/elastic/docs-actions/actions/runs/25039386820
Expected behavior
If gh-aw is asked to create a PR with labels, or if it infers/applies labels as part of PR setup, the labels should be applied promptly and reliably enough that normal opened-event checks do not observe a transient unlabeled PR.
Ideally, gh-aw would either:
- add labels as early as possible immediately after PR creation and wait for that mutation to complete before moving on to slower post-create work, such as requesting reviewers;
- retry or verify label application before reporting the PR as ready; or
- document that PR labels are post-create metadata and may not be present when
opened workflows run, so repositories can trigger required label checks only on labeled/unlabeled or add their own longer retry loop.
Why this matters
Repositories commonly enforce exactly one release-note or changelog label on PRs. If gh-aw-created PRs are briefly unlabeled, required checks can fail despite the PR eventually ending up in a valid state, creating noisy red checks and occasional manual reruns.
Summary
When creating PRs through gh-aw, labels can be applied late enough that
pull_request_targetworkflows triggered by the initialopenedevent see the PR as unlabeled and fail required-label checks. This has happened twice recently inelastic/docs-actions.This does not look like the label-checking action misreading the final PR state. In both cases, the failing run evaluated the PR before the release label was present, and a later run passed once the label existed.
Evidence
Repository: https://github.com/elastic/docs-actions
PR #117
PR: elastic/docs-actions#117
PR created at
2026-04-28T07:00:46Z.Initial
required-labelsrun failed: https://github.com/elastic/docs-actions/actions/runs/25038719070The job intentionally waited 30 seconds on
opened, then checked labels at about2026-04-28T07:01:25Z.Failure message:
Timeline shows the
enhancementlabel was added at2026-04-28T07:01:36Z, after the failed check had already completed.A later
required-labelsrun passed: https://github.com/elastic/docs-actions/actions/runs/25038751464PR #118
PR: elastic/docs-actions#118
PR created at
2026-04-28T07:12:59Z.Initial
required-labelsrun failed: https://github.com/elastic/docs-actions/actions/runs/25039200942The job waited 30 seconds on
opened, then checked labels at about2026-04-28T07:13:40Z.Failure message:
Timeline shows the
fixlabel was added at2026-04-28T07:17:41Z.A later
required-labelsrun passed: https://github.com/elastic/docs-actions/actions/runs/25039386820Expected behavior
If gh-aw is asked to create a PR with labels, or if it infers/applies labels as part of PR setup, the labels should be applied promptly and reliably enough that normal
opened-event checks do not observe a transient unlabeled PR.Ideally, gh-aw would either:
openedworkflows run, so repositories can trigger required label checks only onlabeled/unlabeledor add their own longer retry loop.Why this matters
Repositories commonly enforce exactly one release-note or changelog label on PRs. If gh-aw-created PRs are briefly unlabeled, required checks can fail despite the PR eventually ending up in a valid state, creating noisy red checks and occasional manual reruns.