Some of the instances I manage get an issue with subworkflows after updating to a version >=1.16
Also had one instance of it happening on 1.15 randomly but that was just one flow with this error so could be a fluke.
Sometimes I could fix it by duplicating the sub or main flow and using that, but now also had an instance on 1.18.3 that I could not fix this way so I had to rollback as it was messing up production flows.
this instance where I could not fix it is a enterprise license instance and has all workflows and credentials owned by one user.
Logs show this in some instances and then the execution would be just the workflow without anything that went through (in UI):
At this point I am not updating instances because of this issue.
I have reported this on the Discord as well(month ago), but could not get it reproduced.
After our conversations in slack we identified it was an issue that happened due to the n8n cache becoming inconsistent after the workflow ownership change process that you have implemented.
Unfortunately n8n does not support “changing ownership on the fly”, which required an instance restart to evict the cache and then things would work again normally.
To add to that:
If an instance owner tries execute a subworkflow that is owned by someone else it will result in this error.
It seems to be that manual execution takes into account the person executing the flow and the ownership of subflow, active execution looks at the owner of both workflows.
As you have shown me, this is expected behaviour, which makes sense. But the error that is added for this doesn’t show. Instead we get this error which is unclear to the end user.
Best way around this issue is to never use the Owner account for actual workflow development. As you might use an other persons workflow as a subflow by mistake or whatever causing this issue.
Because we cannot see who is the owner of a workflow on the community version of n8n.
When the error message is fixed it will of course be clear this is the issue.
Thanks for the added context! Yes agree, the error message is unclear but when checking the code, the problem derives from an issue where n8n realizes some credentials were unavailable (due to ownership issues and inconsistencies) and is also unable to generate a proper error message.
We do generate an error based on the credential that failed, but n8n was unable to pinpoint how this error happened and this caused an issue when creating the errored execution.
I checked if we could do something to fix this in our code now and the problem happens here.
n8n cannot find a node to flag the error, then it throws an error with undefined as the node name. When creating a failed execution, n8n cannot find the node name and it has another error, due to the inconsistencies that happened.
