A merged source PR can produce no sync run at all — no run, no failure issue, no artefact

[mmcky]

On 2026-08-19 a source PR merged a new lecture and no sync run was created for it at all — not skipped, not failed, not parked awaiting approval. Absent. The lecture went undelivered with no artefact anywhere recording that anything had gone wrong.

This is a distinct class from the defects already tracked, and it currently has no home.

The incident

lecture-python-intro#839 ("Add Measuring Mobility lecture") merged at 2026-08-19T19:09:02Z, changing lectures/mobility.md, lectures/_toc.yml and lectures/_static/quant-econ.bib. Merge commit d7670896.

Every trigger condition for sync-translations-zh-cn.yml was satisfied:

• the workflow is active (gh workflow list reports it enabled, id 315570533)
• its paths filter is lectures/**/*.md plus lectures/_toc.yml — two of the three changed files match
• its guard is github.event_name == 'pull_request' && github.event.pull_request.merged == true, and the PR was merged, same-repo branch, human author

Yet gh api repos/QuantEcon/lecture-python-intro/actions/workflows/315570533/runs has no pull_request run at or after 19:09:02Z. The newest run naming that PR is an issue_comment run at 04:32:38Z, ~15 hours before the merge, skipped by the trust guard.

The analogous #837 (bivariate_dist, 2026-08-17) fired a pull_request run three seconds after its own merge.

Why it looks like an Actions dispatch gap rather than a workflow-condition bug

Nothing at all fired for that merge commit — not just the sync. The push-triggered Data URL guard (push: branches: [main]) also has no run for d7670896, though it ran for #837's merge and for the Republish push 34 minutes later.

Head-branch-deletion timing does not discriminate: #839's head ref was deleted at +2s, #837's at +3s and lecture-python-programming#612's at +1s — and both of the latter fired normally.

Why it is worse than a sync failure

A failed sync at least opens a translation-sync-failure issue on the source repo with the error and a recovery instruction. A trigger that never fires produces nothing: no run, no issue, no red check, no PR. It is invisible to every count the programme keeps — including the "sync backlog" figure, which counts open sync PRs and so structurally cannot see work that never started.

The gap went unnoticed until a hand coverage audit the next day. The lecture was recovered in lecture-intro.zh-cn#299 via translate init -f.

What would catch it

Not a declared-vs-delivered assertion inside the sync run — there is no run to assert in. Only a periodic reconciliation outside the run:

• the coverage surfacing already scoped on #222 would catch it on the next nightly pass, since the dashboard collector's set diff already computes the missing set correctly
• a lighter, more direct check would reconcile merged source PRs touching docs-folder against sync runs dispatched, per source repo — a gap there is this class by construction

Worth deciding which, since #222 covers the symptom (a lecture is missing) and the reconciliation covers the cause (a run that should exist does not).

Distinct from

• #280 — force-push auto-closes an open sync PR. There, a run happened and a PR existed.
• #276 — resync builds from a stale snapshot. There, a run happens and produces wrong content.
• #234 — runs parked action_required. Ruled out here: no parked run exists on that repo after 2026-08-11, and the PR was human-authored on a same-repo branch.
• The 15 translation-sync-failure issues (all now closed) — those are runs that started and errored.

Frequency

Unknown, and that is part of the problem. One confirmed instance. Nothing in the estate would surface a second one, so the true rate cannot be inferred from the absence of further reports.