A scenario can finish "Success" and still have written nothing — three ways it happens

Knowledge Hub
1

Everyone here has good habits around errors. What I want to ask about is the run that never errors.

Make is unusually honest about this if you read the docs closely: there are documented cases where a scenario stops early or drops a bundle and the execution is still marked Success. That’s by design, and it’s the right design. It just means the run status is not the same thing as “the work got done.”

Three shapes I keep finding.

1. A router route whose filter lets nothing through. The module that writes to the sheet, the CRM, the database sits on one route. The filter on that route stops matching — a field got renamed, a value changed shape — and the route simply doesn’t run. The scenario completes. Nothing is wrong from Make’s point of view, because a filter blocking a bundle is normal behaviour, not an error.

2. A search module that returns zero bundles. Everything downstream on that path executes zero times. Zero times is not an error either. If that path held your only write, the run is green and empty.

3. Error handler directives that are meant to end in Success. Commit stops the scenario immediately, skips the remaining modules, ignores unprocessed bundles, and marks the execution as Success. Resume feeds a substitute value to the failed module and also marks the execution Success. Both are correct behaviour and both are useful. But if a Commit handler sits upstream of your write, there is a class of run where the write never happens and the history shows a green check.

The common thread is that none of this is Make failing. It’s the workflow saying “this is fine” about a case nobody thought about when they built it.

How to check a scenario by hand. No tool needed:

  1. List every module that changes something outside Make — database, Sheets, CRM, Slack, email, HTTP POST / PUT / DELETE.
  2. For each one, ask: is there a route through this scenario that reaches the end without this module executing? Router filters, empty search results, and error handler directives are the three usual ways.
  3. If yes, ask whether that run would show as Success. If it would, decide what you want — an explicit error, an alert, or at minimum a count you can look at later.

I ran a version of this check across 2,043 public n8n templates and 13.5% had at least one high-severity case: a write that can be skipped while the run still reports success. Those templates are curated and polished, so I read that as a floor rather than an average.

I don’t have the equivalent number for Make, and that’s really why I’m posting here. Make’s routers and directives give a scenario more legitimate ways to finish green than n8n has, so my guess is the rate is higher, not lower. But that’s a guess.

So, two questions:

  • Has this bitten you, and which of the three was it — a filter, an empty search, or a directive?
  • Is there a fourth shape I’m missing? I’d rather find out from you than from a client.
1 Like
3

Hey there,

None of these are silent ‘errors’ where Make or n8n is failing. These are places where your design is failing. A piece of code will always do exactly what you tell it to do, not what you want it to do.

For the router issue - don’t use a router, use an if/else module. Then do your ‘error’ on the else path. If no filter matched, throw an error with an http module, or send a slack message.

Same for search modules returning zero bundles. Most of them have an option to continue the execution even if nothing is found. You can handle this with an if/else after it as well.

All in all, these ‘errors’ you are describing are the major reason why you hire an expert to built your workflow instead of doing it your self with an LLM.

1 Like
4

You’re right that none of this is Make failing, and that was the point I was making, badly, if it read as blaming the platform. A scenario does exactly what it was built to do. What I’m interested in is the case where “what it was built to do” includes finishing green while a write never ran.

On the router: agreed, if/else with an explicit error on the else path is the cleaner build. And the option on search modules to continue when nothing is found is a good addition; I didn’t mention it, and I should have.

Both of those are the right fix when you’re the one building the scenario.

Where I keep landing is the case where you aren’t. You take over a client’s Make account and inherit twenty or thirty scenarios someone else built, often someone who has already left. You didn’t design them, you can’t rebuild them all in week one, and the client’s question on day two is “is anything broken?” Nothing has errored. Everything in the history shows Success. So the honest answer is “I don’t know yet,” and finding out means opening every scenario.

That’s the situation I’m trying to make cheap, not a replacement for good design, but a way to triage scenarios you didn’t write so you know which ones to rebuild first.

Since you do this for a living, that’s the part I’d actually like your answer on: when you inherit an account like that, how do you decide what to look at first? Do you go through every scenario by hand, or have you settled on something faster?

5

When I inherit an account, first thing to look at is the documentation. And if that is missing, then every scenario inside is assumed broken and in need of rebuilding.

Also, in my experience, when we are talking proper complex flows, its faster to build it properly from scratch than it is to try and fix it.

6

That’s a clearer answer than I expected, and it mostly argues against what I’ve been assuming. Thanks for it.

Two things I want to understand better, because they’re the parts where my picture and yours don’t line up.

First, the rebuild. When you take over an account with thirty scenarios and no documentation, does the client actually pay to rebuild all thirty up front? In the version I’ve seen, there’s a stretch, weeks, sometimes longer, where the old scenarios are still running in production because the client can’t stop them and hasn’t approved a full rebuild yet. If that stretch doesn’t exist in your work, that changes my thinking. If it does, what do you do during it?

Second, the documented case. If the documentation is there, you presumably don’t rebuild. But documentation tells you what the scenario was meant to do, not what it currently does; someone adds a router branch in month four and doesn’t update the doc. Do you take documented scenarios at face value, or do you still check them against the actual build, and if so how?

Not trying to argue you out of your answer. Rebuilding is probably right more often than I’d assumed, and if the honest conclusion is that agencies don’t triage they replace, that’s worth me knowing before I build anything else.

7

I charge hourly. So it doesn’t matter if I’m rebuilding or updating, if I work 20 hours I charge 20 hours.

If there is no documentation then you pray that the client at least has an overall idea of what is going on. Cause if they don’t and there are system critical scenarios that cannot be stopped, the work becomes twice as long. Cause yeah, first you have to figure out what is going on, then what can be safely fixed and what needs to be done with the main scenarios still running.

And if there is documentation then, how good is it? I mean if it only explains what the scenario is supposed to do, that’s pretty poor documentation but at least it’s a starting point. And if the scenario doesn’t match the documentation, then it’s the same as not being documented at all.

Worst case scenario- there is no documentation at all and the client doesn’t know what’s going on. Then yeah, I check the execution history and start checking from the scenario that runs most often and documenting what the current setup does. Then we figure out what needs rebuilding and what only needs fixing.

1 Like
8

Actually I should have started with this joke I tell all my clients.

A welder goes to a job interview and asks for the salary.
Interviewer says between 15 and 50 an hour.
They have to present a weld for the interview and the welder gets to work.
In the end he presents two welds. First one is exemplary. A text book weld. Second one is barely holding the two pieces together.
Interviewer asks him what’s with the two welds and the welder goes:
“Well the first one is for 50 an hour and the second one is for 15 an hour”.

So depending on what the budget is and what the client wants to get done, there are even more ways on how to approach this situation.

3 Likes
9

That last paragraph is the answer I was fishing for, and it’s not quite what your first message sounded like.

“Check the execution history, start from the scenario that runs most often, document what the current setup does, then figure out what needs rebuilding and what only needs fixing.” That’s triage. You do it; you just do it by hand.

The frequency ordering is the part I want to push on, gently. It ranks by how often a scenario runs, not by how much it can quietly not do. A scenario firing hourly with a write sitting on a branch nothing reaches looks busy and healthy in the execution history, every run green, high volume, top of your list for good reasons that have nothing to do with the actual problem. Meanwhile the weekly one with a router that stopped matching in March is near the bottom.

The bit I’d most like to hear about, though, is “documenting what the current setup does.” Roughly how long does that take per scenario, and how are you doing it, reading the blueprint, clicking through module by module, or something else? From the outside that looks like the expensive step in the whole process, and it’s the one I have the worst picture of.

Also, you’re right that the doubled-work case is the real one. “System critical scenarios that cannot be stopped, and nobody knows what they do” is a better description of the problem than anything I wrote in the original post.

And the welder joke lands. A lot of what gets inherited was built at 15 an hour and is now expected to behave like 50.

If you’d find it useful, I’m happy to send you what I’ve built so you can poke holes in it. The mods stripped the link from my first post, fairly enough, so I won’t put it back in the thread. DM works if you want it.

10

Well at this point it joust sounds like you are deliberately misinterpreting what I’m saying just to fit your narrative so you can sell me a solution to a problem you imagined.

Of course I don’t do any of that by hand.

There is zero chance your software works in 100% of cases because everything is variable and case by case dependent.

There is zero chance I’m spending money on it as well.

11

Great writeup, saving this.

number 2 is the one that’s bitten me a search module comes back empty because a field got renamed upstream, everything after it quietly skips, scenario’s green, nobody notices till someone asks where a record went.

fourth shape: aggregators. if one sits downstream of a search/iterator that returned zero bundles, it just outputs empty instead of erroring, and anything after it treats that as a normal result.

your manual check is solid, I’d just add “does this module assume it’s getting something non-empty” catches the aggregator case too.