n8n logon8n Automation Hub
← All articles
Debugging notes

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

Debugging notes · n8n workflow · September 19, 2026

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.

Workflow at a glance
  1. The publisher reads the oldest ready row, downloads the video over SSH, uploads it to YouTube, downloads the thumbnail over SSH, uploads the thumbnail, marks the row published and notifies
  2. In both runs the upload node succeeded and returned an upload id; the next node, the thumbnail download, failed with SFTP No such file
  3. Execution stopped there, so the mark-published node never ran and both rows still said ready
  4. A scheduled run would have picked the same rows up again and uploaded them a second time
  5. Fix: let optional steps continue on error, record the upload right after it happens, or check that the files exist before anything irreversible

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

  1. 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.
  2. 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.
  3. 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.

Uploads that go live while your queue says otherwise?

I reorder publisher workflows so the irreversible step is always recorded first.

Join the Telegram channel Hire me on Fiverr View my Nexus profile