A failed delivery does not necessarily mean nothing happened. Your workflow may have created a branch, written a commit or opened a pull request before losing the response. Pressing Execute again can create more work instead of recovering the original attempt.
A useful duplicate guard gives the article a stable identity, claims its delivery destination before writing files, and stops when existing state is ambiguous. This guide follows the repository implementation reviewed on 30 September 2026 and uses offline examples. It does not claim that a fresh live delivery was replayed successfully.
Start with the introductory automation guide if your pipeline does not yet separate writing, review and delivery. Here the starting point is an already reviewed package. Generating another article is outside the recovery procedure. The public source manifest validator can check review-record structure before delivery, while factual approval remains editorial work.
Decide what counts as the same delivery
Give the proposed article a canonical slug when its brief is accepted. A fictional article named “A Repeatable Review Queue” might use repeatable-review-queue. Keep that slug unchanged when the same approved package is retried.
Record a request identifier separately. It connects the attempt to its editorial history, but a new execution identifier should not create a new article identity. Otherwise each retry appears new to the system that is supposed to recognize it.
Also record the approved body hash and the image hashes. These answer a different question: are these the same approved bytes? A stable slug with a changed paragraph is a revision requiring review, not permission to overwrite the earlier delivery.
In this implementation, the branch name is derived from the slug: editorial/auto- followed by the article slug. That makes the slug the collision boundary. Deliberately changed slugs can bypass it, so policy and editorial review must prevent accidental alternate spellings from becoming duplicate articles.
Check the published destination first
Before preparing remote objects, read the exact article path on main. The repository workflow accepts a missing-file response, stops if the article exists and also stops if the lookup cannot establish either outcome. An authentication error or service failure must not be interpreted as an empty destination.
This is a new-article delivery path. Updating an existing article should use a separate reviewed change with an explicit diff. Do not delete the existing article, rename the incoming slug or suppress the guard just to make the original creation path continue.
The check alone cannot prevent every race. Another process might publish the same destination between the read and the later write. Keep a final diff review before merging, restrict independent writers where practical, and avoid presenting a preliminary lookup as a complete concurrency solution.
Reserve the branch before writing the package
The next step creates the stable branch reference from the observed main commit. Only after successful reservation does this workflow create file blobs, assemble a tree, create a commit and advance the editorial branch.
GitHub documents separate operations for references, trees and pull requests. There is no single transaction here that simultaneously reserves a branch, commits every file and creates the review request.
If the reference already exists, stop and inspect it. Do not turn every validation error into “duplicate delivery”: malformed input and other API failures can also prevent reference creation. Read the response and compare the exact reference before classifying the outcome.
Branch reservation is itself an external write. Its benefit is that it occurs before the content-writing side effects. An abandoned reservation is therefore an expected recovery case, not evidence that the whole operation remained untouched.
Treat partial states differently
A successful delivery produces a review branch containing the article, images and repository receipt, followed by a draft pull request. The final workflow response also reports the pull request URL. Those two kinds of receipt are useful but have different failure windows.
If the branch exists at its original base commit, reservation may have succeeded while file delivery did not. If the branch points to a new commit with a matching package but no pull request, the content stage may have completed before review creation failed. If a pull request already exists, a missing final response does not justify opening another one.
Conversely, a receipt file by itself does not establish that a pull request exists, was reviewed or was merged. Inspect the branch contents, approved hashes and actual pull request state together. Preserve the observations before changing anything.
An n8n Data Table can store delivery markers and help operators find prior attempts. Do not assume that a read followed by an insert is an atomic lock. Concurrent writers require a separately tested reservation mechanism with clearly defined behavior.
Reproduce the guard without live writes
The companion offline checks exercise the current duplicate-check Code node with an existing-file response, a missing-file response and an unexpected response. They also verify the delivery node order so branch reservation precedes blob creation. These are local tests of repository logic, not calls to GitHub or executions in n8n.
A separate small simulation uses one fictional slug twice and records its state after each attempt. The second attempt must leave the simulated branch head, commit count and pull request count unchanged. A partial-reservation case must remain blocked for investigation. The simulation documents the intended behavior; it cannot prove remote race handling or network recovery.
For an authorized live test later, use a disposable private test destination and one approved synthetic package. Record the starting branch head, run once, then submit the identical payload. Compare the reference and counts before and after, and capture both outcomes without account identifiers or credentials. Never use a published article as a convenient replay fixture.
Recover deliberately
Pause automatic retries for the affected identity. Find the exact branch and every related pull request, including closed requests. Compare the current main path, branch tree, receipt and approved hashes. If any part differs, send the discrepancy to editorial review before continuing.
When the package is intact but the review request is missing, an authorized operator may resume only the missing step after checking for an existing request. When only a reservation remains, preserve the evidence and decide whether to repair or replace it. Deleting a branch is not a harmless reset if someone added valid work after the failed attempt.
The Delivery Reconciliation Reporter, WF13 v0.1.0, was publicly released on 30 September 2026. Workflow code and documentation use MIT, with separate image and supplied-content rights. This offline classifier reads caller-supplied snapshots; observations_authenticated remains false, and it does not fetch GitHub state. Its report leaves retry_allowed and release_approved false and grants no permission to delete, overwrite or replay delivery.
The practical goal is a clear answer to three questions: what identity was claimed, what bytes were written, and what remains unfinished? Once those answers are recorded, recovery can be a narrow reviewed action instead of another full run through the pipeline.
Verification evidence
Duplicate guard verification; observed 30 September 2026. offline repository code / no github write. Rendered report, not a product UI screenshot. The original image retains its private-review label; the owner approved this historical report for publication on October 1, 2026.
Image provenance and reuse limits: publication asset manifest.