Duplicate Actions workflow dispatch from a single push trigger

[lancewillett]

Related to #633

The WordPress/wordpress-develop SVN→GitHub mirror has emitted two distinct GitHub push events for the same branch update on at least two occasions.

August 12, 2026 occurrence

At 12:20:10 UTC, GitHub recorded two PushEvents for the same update to refs/heads/7.0:

• before: 83570840777b037c2df030f933443ca41c663450
• head: 0925e93d05fabb02c539f05bd0513d8855f38bf3
• push IDs: 39799858125 and 39799858906
• event IDs: 17479793011 and 17479793715

The duplicate push created 22 GitHub Actions runs across 11 workflows and 35 cancelled jobs. The workflows then retried cancelled runs automatically, amplifying the churn.

Example duplicate runs:

• ​https://github.com/WordPress/wordpress-develop/actions/runs/31595940424
• ​https://github.com/WordPress/wordpress-develop/actions/runs/31595941567

Prior occurrence

On May 19, 2026 at 14:01:12–14:01:13 UTC, branch 7.0 produced two push-triggered runs for the same head, 567ec46ec18ba761a3c37375a775a98a7c73be4f:

• ​https://github.com/WordPress/wordpress-develop/actions/runs/26102236340
• ​https://github.com/WordPress/wordpress-develop/actions/runs/26102236520

Across the latest 1,000 push-triggered Cleanup Pull Requests runs, these were the only duplicate-head pairs, and both affected 7.0.

Mirror context

#633 documents the Git-server post-receive hook as running:

git push -f --mirror git@github.com:WordPress/wordpress-develop.git

GitHub attributes deploy-key pushes to the repository administrator who verified the key. The pento actor shown on these events therefore does not imply a manual push.

A sequential unchanged bare mirror push reports Everything up-to-date and sends no ref update. The duplicate records instead suggest either overlapping mirror invocations or duplicate processing inside GitHub.

Requested investigation

Could Systems inspect the Git mirror's post-receive and outbound SSH logs around these UTC windows?

• August 12, 2026, 12:20:05–12:20:15
• May 19, 2026, 14:01:05–14:01:20

The key question is whether git push -f --mirror ran twice.

• If two mirror invocations appear, the hook may need single-flight locking or coalescing.
• If only one outbound push appears, the push IDs and event IDs above should support escalation to GitHub Support.

[barry]

On the WP.org side this sync runs via cron every minute and has a lock file so I don't see how we would end up with duplicates. I downloaded the git logs from Github and see the following push events on wordpress-develop around the time in question on August 12, 2026:

{
  "@timestamp": "2026-08-12T12:18:09Z",
  "_document_id": "P9gEEPccl-pHBhSW4J4cCA==",
  "action": "git.push",
  "actor_id": 0,
  "business": "wordpress-foundation",
  "business_id": 191580,
  "org": "WordPress",
  "org_id": 276006,
  "repo": "WordPress/wordpress-develop",
  "repository": "WordPress/wordpress-develop",
  "repository_id": 75645659,
  "repository_public": true,
  "request_access_security_header": "",
  "request_id": "8cfd6d7f6426ffd4c929be024e9594b9",
  "transport_protocol": 2,
  "transport_protocol_name": "ssh",
  "user_agent": "git/2.47.3",
  "user_id": 0
}
{
  "@timestamp": "2026-08-12T12:20:09Z",
  "_document_id": "ltwXjt9QkltHUGBY50GzEA==",
  "action": "git.push",
  "actor_id": 0,
  "business": "wordpress-foundation",
  "business_id": 191580,
  "org": "WordPress",
  "org_id": 276006,
  "repo": "WordPress/wordpress-develop",
  "repository": "WordPress/wordpress-develop",
  "repository_id": 75645659,
  "repository_public": true,
  "request_access_security_header": "",
  "request_id": "97304ee7166cebb28425b781e9c12739",
  "transport_protocol": 2,
  "transport_protocol_name": "ssh",
  "user_agent": "git/2.47.3",
  "user_id": 0
}
{
  "@timestamp": "2026-08-12T12:21:08Z",
  "_document_id": "UV9gKQf_6FnLBjIyU6bi3w==",
  "action": "git.push",
  "actor_id": 0,
  "business": "wordpress-foundation",
  "business_id": 191580,
  "org": "WordPress",
  "org_id": 276006,
  "repo": "WordPress/wordpress-develop",
  "repository": "WordPress/wordpress-develop",
  "repository_id": 75645659,
  "repository_public": true,
  "request_access_security_header": "",
  "request_id": "5ee01505dde351900823d531e5f34afd",
  "transport_protocol": 2,
  "transport_protocol_name": "ssh",
  "user_agent": "git/2.47.3",
  "user_id": 0
}

There are no duplicates. So it seems like this is probably an issue on the Github side?

[lancewillett]

@barry Could you please pull the same audit log for May 19, 2026 between 14:01:05 to 14:01:20 UTC? If that one also shows a single git.push we'll have two independent cases of one push becoming two events, which makes a much stronger report to submit to GitHub support.

[barry]

Replying to lancewillett:

@barry Could you please pull the same audit log for May 19, 2026 between 14:01:05 to 14:01:20 UTC? If that one also shows a single git.push we'll have two independent cases of one push becoming two events, which makes a much stronger report to submit to GitHub support.

Sorry, I should have mentioned this originally but the Github.com git logs only go back 7 days so logs aren't available for that timeframe.

[lancewillett]

Filed with GitHub Support as ticket 4658599, under the WordPress organization.

We believe GitHub received one push and recorded two.

Retention puts the May 19 window out of reach, but both run records are still live in the REST API, 26102236340 and 26102236520, same head 567ec46e, created one second apart. Those went into the ticket so GitHub can correlate against their own logs.

@barry one more ask while the window is still open.

The audit log also records workflows.created_workflow_run, available through the REST API, log streaming, or a JSON/CSV export, but not the web interface.

For the August 12 duplicate it would show whether each run has its own creation record, and whether they trace back to one ingestion or two.

Could you pull that for WordPress/wordpress-develop between 12:20:00 and 12:20:30 UTC on August 12? The two runs are 31595940424 and 31595941567.

(I don't have org admin rights.)

[lancewillett]

With help from Barry, audit logs from GitHub org help shine a light here.

All 22 workflow runs share one request_id, 97304ee7166cebb28425b781e9c12739, and one trigger_id, 39799858125. That request_id is the single git.push entry at 12:20:09 UTC. One actor, one token. There was no second push and no webhook redelivery.

The runs were created in two batches from that one trigger. Batch A: 11 events across 12:20:12.096 to 12:20:12.188. Batch B: the same 11 workflows across 12:20:12.897 to 12:20:13.151. A 709 ms gap sits between them. Non-Actions apps each received exactly one check suite; Actions created two.

So the duplication happens inside Actions, downstream of trigger resolution. The post-receive hook and git push -f --mirror are not implicated. The two push IDs visible in the public Events API do not both appear as triggers, only 39799858125 does.

Filed with GitHub Support as ticket 4658599 and updated with this evidence. Given the above, this ticket's title is misleading and worth changing.

[lancewillett]

New ticket title suggestion: Duplicate Actions workflow dispatch from a single push trigger.

I don't have Meta Trac edit permissions.

[barry]

Replying to lancewillett:

New ticket title suggestion: Duplicate Actions workflow dispatch from a single push trigger.

I don't have Meta Trac edit permissions.

Updated the title.

[lancewillett]

Resolved upstream. GitHub Support confirmed the root cause on August 24 (ticket 4658599).

This was not the SVN mirror, and it was not two pushes. A single push was duplicated inside GitHub's event pipeline before workflow dispatch: one real push produced two webhook delivery GUIDs, and each delivery queued all 11 matching workflows independently. That is why the audit log shows one git.push entry and one trigger id, yet two complete sets of workflow runs and check suites on the same commit.

GitHub's engineering team explicitly ruled out: two independently generated push events, replay by a downstream consumer, one dispatch job invoking workflows twice, a retry of either dispatch job, same-GUID webhook redelivery, a duplicate-key race in the dispatcher, workflow reruns or run_attempt handling, and our own workflow configuration.

They classify it as a known edge case and confirmed it is isolated rather than systemic. On the day in question, 78 push deliveries to this repository produced 2,150 workflow-run creation events, and only this one duplicated.

The cancellations seen alongside it were not a second fault. cleanup-pull-requests.yml uses concurrency with group: ${{ github.workflow }}-${{ github.sha }} and cancel-in-progress: true, so two runs on the same SHA share one concurrency group and the first is cancelled by design.

No change is needed on the WordPress side. GitHub asked to be told if it recurs.