An article can finish generating successfully and still fail to reach GitHub. Treating the whole execution as disposable at that point risks losing useful files or paying to generate the same content again.
A safer recovery path separates the content package from its delivery attempt. Keep the approved MD, HTML, PDF and ZIP, return a clear failure receipt, and investigate the remote state before repeating any write. This article examines that boundary in AI Content Machine's editorial workflow.
The source reviewed is main commit 3d118333, which includes the PR #53 recovery integration. The production delivery validator was updated to v0.5.1 on 30 September 2026; the checked-in workflow name remains v0.5.0. No new live delivery or paid generation was run for this article. Historical integration evidence and new offline checks are labelled separately.
Classify the failed operation first
Start with the last confirmed operation, not a generic red execution badge. There are several materially different cases.
An input rejection means the package failed its contract: approval is missing, an image changed, a path is unsafe or a required field is malformed. Repeating unchanged input cannot fix that. Correct the source record, then obtain another review if the approved content changed.
An authentication or authorization failure needs an account or permission check. Repeated requests do not repair access. Avoid copying credentials into notes or receipts while investigating it.
A duplicate branch response can mean the protection is working. The saved delivery failures examined for this project reported HTTP 422 with Reference already exists at Reserve Editorial Branch. That specific message identifies a collision. HTTP 422 in general can indicate other validation failures, so retain the actual operation and response instead of treating every 422 as a duplicate.
A timeout or connection loss after a write has an unknown outcome. GitHub may have accepted the request even though n8n did not receive the response. Keep that case unresolved until a read-only inspection establishes what happened.
Choose retries by effect
A read-only status request and a paid generation call have different retry consequences. For an unavailable read endpoint, a future recovery policy can use a small attempt limit and delay, while respecting provider rate-limit guidance. It should record when it stopped.
For a write with an uncertain result, inspect before retrying. Check the deterministic branch, expected commit and associated pull requests. If the expected PR already exists, capture its identity instead of creating another one. If only part of the package exists, keep it for review; do not automatically delete the branch or force its reference.
The reviewed delivery implementation has no automatic retry loop. That is an observable implementation limit, not a claim that retrying can never be useful. A future retry policy needs explicit operation-level conditions and a safe way to reconcile unknown outcomes.
Similarly, do not release a budget or editorial reservation solely because a timer expired. If generation or delivery might have completed, releasing the reservation can allow a second worker to repeat the same paid work. Escalate the ambiguity while keeping the existing evidence.
Preserve exports independently of delivery
In the current integration, the Generate MD HTML PDF node creates the download package before the delivery subworkflow runs. The parent waits for that subworkflow and is configured to continue to a recovery node when it errors.
The recovery node retrieves the original exporter item explicitly. It copies its JSON and binary fields into the final item, then adds a delivery_receipt binary containing JSON. That ordering is important: reconstructing an item from the delivery response alone would discard the original download fields.
The success check is deliberately narrow. It requires the awaiting_merge status and a pull-request URL matching the expected GitHub repository. Otherwise, the result becomes delivery_failed. A reassuring message without a confirmed destination is not accepted as delivery success.
The September 30 offline harness ran this actual recovery-node code with fictional binary descriptors. It checked success, a simulated branch collision and an untrusted URL, confirming that the original download descriptors remained identical and a receipt was added. This verifies the handover logic; it does not prove that a newly generated PDF renders correctly or that a live download is still available.
Keep the failure receipt useful and safe
The implemented download receipt is intentionally modest. On failure, it says the files were generated but GitHub delivery was not completed, and instructs the operator to inspect the execution before repeating it. It does not contain a complete remote-state diagnosis.
Keep richer operational evidence in an appropriately restricted incident record. A useful record can include a fictional or approved request identifier, package hashes, attempted branch, last confirmed step, sanitized error category, attempt count and the next read-only check. Do not claim these fields already exist in the current minimal receipt.
Exclude access tokens, authorization headers, raw model prompts, private article contents and unnecessary user identifiers. A receipt is often downloaded or forwarded more widely than an execution log. Record only what is needed to recover the specific job.
The generated package also needs a retention plan. The recovery node keeps files in the current result; it does not provide indefinite storage. Download or archive the approved files through an authorized destination before execution retention or cleanup removes access. Check the actual instance policy rather than assuming saved executions last forever.
Use Error Trigger for the right boundary
n8n's current Error Trigger documentation describes a separate error workflow beginning with Error Trigger. Save it, then choose it in the source workflow's Error workflow setting. The error workflow itself does not need to be published.
The same documentation states that Error Trigger runs for failures of automatic executions, not manual test runs. A successful manual recovery demo therefore cannot establish that your global Error Trigger is configured correctly. Also, execution identifiers and URLs depend on saved execution data, and trigger failures can provide a different payload.
This tutorial's preservation path is local to the parent workflow. Because it handles a delivery error and continues, do not assume a global error workflow will also fire for that handled failure. Test alerting separately in a permitted isolated setup before relying on it operationally.
The Execute Sub-workflow reference explains waiting for a child workflow and passing its result back. Review those settings alongside the parent's error behavior; the two together determine whether the recovery node can inspect the result.
Read the historical result honestly
The retained TEST pull request #52 is closed without merge. Its recorded integration test used existing approved material and synthetic review identifiers. The historical recovery record reports preservation of MD, HTML, PDF and ZIP plus a failure receipt after duplicate rejection. Those observations belong to the earlier test, not a fresh run for this article.
For a future authorized demonstration, use fictional inputs and capture the failure branch and download result without exposing credentials or private execution details. Verify each downloaded file and hash, then record exactly which run produced it. A rendered offline verification report accompanies this article. A real execution/download capture remains pending.
The existing topic validator tutorial covers preventing avoidable generation. At this later stage, preserve completed work and establish what reached its destination. The Delivery Reconciliation Reporter, WF13 v0.1.0, is publicly available as of 30 September 2026 under MIT for its workflow code and documentation, with separate image and supplied-content rights. It classifies supplied snapshots offline, always leaves retry_allowed and release_approved false, and does not independently verify remote state. n8n executions, storage and provider usage still depend on your plan and policy.
Verification evidence
Recovery logic verification; observed 30 September 2026. offline node test / fictional binary descriptors. 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.