n8n Automation Hub
Bug one: a stub node that quietly erases the data behind it
A no-op utility node earlier in the workflow — meant only to confirm a file had been written over SSH — was returning its own output object instead of passing the real data through. Everything downstream that assumed the previous node's data was still there broke on an undefined value the moment it tried to read from it. The fix was pulling from the actual named upstream node instead of trusting whatever the immediately-previous node happened to output — but the more useful finding was that this exact footgun had already been hit and documented in a comment on a different node in the same workflow. It just hadn't been checked everywhere the same SSH-node pattern repeated.
Bug two: a length limit that only existed in the prompt
The video title comes from an LLM call with an instruction to keep it under 100 characters "if possible." That's not a limit, it's a suggestion, and the upload API doesn't negotiate — a title a few characters over rejected the whole upload with a generic "invalid title" error that didn't say why. Prompt-only constraints on LLM output are not enforcement. I added an actual code-level cap on both the title and the tag string, trimmed at a word boundary, so the platform's real limit can never be violated regardless of what the model decides to generate.
Bug three: dedup that had never actually run
The node responsible for reading the log of already-covered stories — the thing that's supposed to stop the same story from getting covered twice — was a literal stub returning an empty array. It had been like that since the pipeline launched. Every day's dedup check was comparing new stories against nothing, which meant cross-day duplicate protection had silently never worked, not once, the entire time the channel had been live. Wiring it to actually read the log it was already writing to fixed a bug that had been there from day one and never once shown up as an error, because an empty comparison list isn't a crash — it's just wrong.
Bug four: the same background image for unrelated stories
Three same-day segments — a wildfire, a drought summit, and a flood evacuation, three genuinely different stories — all rendered with the same generic sunset-desert image. The image-prompt step used one fixed style template per category, and that template was strong enough to dominate the output regardless of what the actual story was about. Adding random seed variation didn't fix it — the template still won. What worked was replacing the single template per category with several keyword-matched variants, chosen by scanning each segment's actual text for relevant terms, with a fallback that still rotates even without a keyword match.
Why none of these ever threw an error
Every one of these bugs produced a technically valid output — an empty array is valid, a duplicate image is valid, a rejected upload still returns an error the workflow can catch and move past. The execution log had no reason to flag most of it as an actual failure. The only way to catch this class of bug is to actually look at what a workflow produces, not just whether it finished — and to be suspicious of any node whose "success" is a default or a stub rather than something it actually did the work to produce.