The idea is that when the the workflow is opened via the execution page, the execution data is somehow passed through, sou you can debug it and interact with it, as if you were executing the workflow for the first time.
When checking the past executions, you can visualize the execution data “statically”, and you can’t interact with it. You have the option to open the workflow, but then the execution data is lost, so all the n8n power of manipulating data in real time is not used in this context.
This would open 2 big possibilities:
Debugging past executions interactively when workflows do not fail! Sometime a successful execution is not exactly successful. You could successfully send incorrect data somewhere, for example. In that case, there is no way (afaik) to debug utilizing the real data, you have recreate the data, which is not ideal, and sometimes pretty much impossible.
Debug nodes executed via “Execute Workflow”. The “Execute Workflow” is essential in my day to day n8n usage, but I found them very hard to debug. You can save manual executions, and then check the execution data for sub workflows, but they’re read only, and you can’t debug them. When workflows start to get complex, with workflows calling workflows calling workflows, my biggest nightmare is having to debug one of those nested workflows. The best way I’ve found to do it is to un-nest al the subworkflows on the main workflow, and then execute it there, so I can follow the workflow. Once I’m satisfied, I have to remember what I’ve changed, and bring it back to the sub workflow, because simply copy-pasting everything could break references. That is really error-prone, and you get that feeling that that’s not the way to do it. But yeah, sub workflows are essential to my usage, so I do that anyway…
I’ve found someone have already pointed this last topic:
