The Video Uploaded, the Thumbnail Download Failed, and the Queue Row Was Never Marked Published

Two manual test runs of a publisher workflow both ended in a red node. Both had already uploaded their video. The failing step was a thumbnail download, and it sat in front of the one step that records that the upload happened.

The order of operations

Get ready row -> Download video (SSH) -> Upload to YouTube
   -> Download thumbnail (SSH) -> Upload thumbnail -> Mark row published -> Notify

The video upload is the one step that can't be undone. Everything after it is bookkeeping and extras. The thumbnail steps sat between the upload and the mark-published step, so an error in any of them stopped the run before the row was updated.

What the two runs showed

On September 17 I fired a publisher workflow twice by hand, once for a long video and once for a short. In both executions the YouTube upload node finished successfully and returned an upload id. The next node, the SSH file download for the thumbnail, failed with an SFTP No such file, code 2. The mark-published node never ran. That is the part that matters: the video was live on YouTube while the queue still said it was waiting.

The error doesn't name the file

The message is just No such file. The path isn't in it. It's in the row the workflow picked: the output of the Limit node shows the video and thumbnail paths, and checking them on disk showed the thumbnail was missing in both cases. The files' timestamps show they were created a few minutes after the failed runs. Why they hadn't been created is the subject of the empty-base64 article; the lesson here is that the publisher trusted a path the queue row recorded.

Three ways to fix it

Make optional steps continue on error. On both publisher workflows the thumbnail download node now has onError: continueRegularOutput, so a missing thumbnail no longer blocks the bookkeeping. The thumbnail upload after it needs the same setting.
Record the upload right after it happens. Move the mark-published step directly after the upload, or add an intermediate status such as uploaded, so the irreversible step is written down the moment it succeeds.
Check before you commit. Run test -f for both files over SSH before the upload node, and fail early when either is missing, while nothing has been published.

The first is quickest, the second is the most robust, and the third gives the cleanest failure. They combine well.

A test run of a publisher is a real publish

Both manual runs above produced real uploads. It is the reason to prefer reading past executions over firing a publisher by hand whenever you can. The duplicate-publish article covers a different cause of the same symptom, matching rows on a column that wasn't unique.

The publisher after the fix, step by step

Get Ready Rows -> Sort -> Limit to 1
  -> SSH: test -s video.mp4 && test -s thumbnail.png   (exit code checked)
  -> Download video (SSH)
  -> Upload to YouTube
  -> Mark row uploaded (Sheets, key = row_id)              <- right after the irreversible step
  -> Download thumbnail (SSH, On Error: Continue)
  -> Upload thumbnail (On Error: Continue)
  -> Mark row published -> Notify

The order is the point. Everything that can fail without harm sits after the step that records the upload, and the only check that can stop the run happens before anything is published.

Which n8n "On Error" setting to use where

Setting	What happens on failure	Good for
Stop Workflow (default)	The execution ends with an error	Steps that must succeed before anything irreversible
Continue (regular output)	The node passes an item with the error on to the next node	Optional extras such as thumbnails or a second notification
Continue (using error output)	A second output branch receives the failed items	Cases where a failure needs its own handling, such as an alert or a fallback

One caution with Continue (regular output): the next node receives an item that describes the error, not the data it expected. If that next node reads fields from $json, it gets nothing. Referencing the source node by name, as in $('Limit to 1').item.json.video_path, avoids that.

Finding rows that were uploaded but never marked

If a publisher has already failed this way, there are live videos whose queue rows still say ready. Before the next scheduled run, compare the two sides: list the channel's recent uploads with the YouTube Data API and match their titles against the ready rows. Any match is a row to mark published by hand. Otherwise the next scheduled run uploads the same video again.

Frequently asked questions

Why was the video live while the queue still said ready?

The upload succeeded, but the thumbnail download after it failed and stopped the execution. The node that marks the row published came later in the chain, so it never ran.

Which n8n setting lets an optional step fail without stopping the run?

In the node's settings, set On Error to Continue (regular output), or to Continue (using error output) if the failure needs its own branch.

Where should the mark-published step go?

Directly after the irreversible step, the upload. Bookkeeping that comes after optional steps is lost whenever one of those steps fails.

Is a manual test run of a publisher workflow safe?

No. It performs a real publish. Prefer reading past executions, or point a copy of the workflow at a test channel.