Pinning Data is great feature… but doesn’t work for me. I pin data to keep my upstream nodes from firing (they are loooong running) but, when I do a test run of the node it reruns the upstream nodes anyway. (sigh)
I have a simple two node setup. Node A is a Code node, who’s output is pinned (the nodes upstream of this are long running). This one feeds in to B which is a HTTP Request Node. If I try to test the HTTP Request Node, it should just pull its data from the pinned data of A, but instead it starts running nodes upstream of A… the exact opposite of what is intended.
Any assistance would be greatly appreciated.
Information on your n8n setup
n8n version: 1.83.2
Database (default: SQLite): postgreSQL
n8n EXECUTIONS_PROCESS setting (default: own, main): Do not understand this question
Running n8n via (Docker, npm, n8n cloud, desktop app): Docker
Operating system: Windows 11 Pro (Version 10.0.26100 Build 26100
)
Note that I am running with: N8N_RUNNERS_ENABLED=true
Not sure if it still works, but at one point when this has happened to me, I managed to get through testing by temporarily adding a manual trigger and connecting it directly to the node with pinned output. Also, position the temporary manual trigger node on the editor above and to the left of everything else. n8n chooses what to run first by how things are arranged relative to each other in the editor.
You could give that a try. Hope it works in your situation.
I did something similar where I just disconnected the node with the pinned output from the workflow. That certainly did the trick… but, still seems like a bug to me.
I think it has been reported quite a few times. I think I’ve noticed someone mentioning it on discord every week or two at least. The issue, I think, is that executing something in the middle of a workflow is already making a lot of assumptions about what the process-state would be, and there are things that just can’t be reconstructed without the actual context.
For instance, if any expression were to reference a node other than the one immediately prior, like $('some node 5 steps back').item.json.someFieldValue instead of $json.fieldValue, what is the "Test step" button supposed to do? The only way to resolve the execution data from previous steps is to trigger a re-run of those steps.
I think there are just some scenarios, also including aspects of execution state other than expression references, where it isn’t possible for n8n to run a single step in isolation.
Another trick you might try is to shift the “dummy response” out into a test-version of the long-running process to short circuit that and get through the workflow/orchestration testing part more quickly.
I hope you can find ways to scaffold for development and get things working.
You might be onto something about what is being referenced, however the counter to that is that if I disconnect the pinned node, it (kind of obviously) doesn’t return former upstream nodes… but also the downstream node uses the pinned data correctly (it operates as expected).
So this means that the pinned data was comprehensive enough. Ifso facto, that must mean it didn’t need to run the upstream nodes at all. Also, even if it did need to do this, I’d prefer an error telling me what it didn’t have that it needed so I could reconfigure.
So to me, this still seems more in the bug category. Certainly it defies reasonable user expectation and it flies in the face, near as I can tell, of the documented behavior of pinning.
to me.