I spent about a year building an autonomous multi-process agent system for my own use. At some point I wanted to check retroactively whether its success reports were true, and I found I couldn’t: my own log schema had no field pointing at anything outside the log itself. No record id, no commit, nothing. The reports weren’t wrong. They were unverifiable.
Then I found something I hadn’t expected. A failed fetch in Node throws no error. The call goes nowhere, the agent reports done, and the run is green. About 19,000 of those had accumulated before I noticed.
So my question to people running n8n or Make in production, especially for clients: when a node writes to an external system - a CRM record, an invoice, an order - how do you establish that it actually arrived?
Do you read it back afterwards, or do you trust the return value?
I am not asking about monitoring that alerts you when a run fails. That part seems well covered. I mean the other case: everything green, nothing happened.
Curious whether this is a real problem for others or whether I just built mine badly.
Your problem is probably the fact that you are using agents do do everything.
If you develop a deterministic flow you can build in checks to make sure everything is properly processed. Usually this involves logging and checking in the workflow it self to make sure all is good.
fair, and you’re right that a lot of this comes from me leaning on agents where a deterministic flow would have been better. also true that the raw fetch thing is a node problem more than an n8n one, the http node does error out by default.
what i’m still unsure about is what “checks in the workflow” means in practice. do you mean checking the response you got back, or actually querying the target system afterwards to confirm the record is there?
asking because the case i keep running into is a 200 that comes back fine and still nothing was written, or a continue-on-fail branch that keeps the run green. curious whether reading back is something you’d ever bother with or whether that’s overkill in real projects.
@Toxly I would assume both, because checking the response you got and ensuring that the record is there will ensure that your workflow isn’t giving anymore false positives. You can grab the ID the write returns and get it from the target to confirm it’s there
yeah that’s where i ended up too, grabbing the id back and reading it from the target.
genuine question though, and not a dig: do you actually do that in your own builds, or is it more the thing you’d do if the project had the budget? asking because so far everyone agrees it should be done and nobody has said they actually do it. if it’s the second, that’s interesting on its own.
I haven’t done it myself, because I haven’t had a situation where I’ve needed to do that, but if I started storing mass amounts of data in a database or something similar, I would add that in for sure.
that’s actually the most useful answer i’ve gotten, thanks. “haven’t needed it” is exactly what i was trying to find out.
i think my case was specific to raw node, where a failed fetch doesn’t throw at all, so the run stays green and nothing surfaces. inside n8n that doesn’t really happen the same way, which probably explains why it never came up for you.