Why does my subworkflow trigger error 'Cannot read properties of undefined (reading "disabled")'?

Below is an analysis of the situation and some troubleshooting steps based on similar issues seen with subworkflows and execution sequencing in n8n:

---

What the Error Indicates

The error

  "Cannot read properties of undefined (reading 'disabled')"

suggests that during workflow execution an expected object is missing. In most cases, this happens when a node’s configuration or output isn’t available as expected. For example, the code is trying to access the property "disabled" on an object that hasn’t been defined—often because:

• A node that should have executed didn’t run
• The workflow wiring isn’t ensuring that the necessary node is processed first
• There is a version/configuration mismatch unexpectedly affecting node properties

---

Specific Context in Your Workflow

In your case the error happens when transferring data from a main Telegram workflow (processing a CSV file) to a subworkflow. The fact that the error occurs only when going to the next subworkflow (and not when triggering the subworkflow manually) is a strong indicator that one or more nodes in the prior step may not be executing, leaving expected properties (like “disabled”) undefined.

---

Troubleshooting Steps

1. Check Node Execution Order and Wiring
   Ensure that every node that is referenced downstream is actually executed. If one of the required nodes (in the main or subworkflow) did not run, subsequent nodes that rely on its output might try to access properties (for example, a “disabled” flag) that aren’t defined.

2. Test the Workflow Incrementally
   • Use the "Execute Workflow Trigger" option on sub-parts of your workflow to verify that expected data is present.
   • In nodes that use expressions referencing previous nodes, add a check (for example, testing with JavaScript using the syntax:

   JSCopied
   $("node-name").isExecuted

   ) to ensure the node has run before accessing its output.

3. Review Subworkflow Configuration
   Since the trigger from the main workflow to the subworkflow is failing, double-check that the subworkflow has been updated correctly and that its structure is compatible with your n8n version (1.77.3 in your case). Sometimes changes or discrepancies in node configuration between versions can lead to missing properties.

4. Reset or Reopen the Workflow Editor
   Sometimes a simple reset of the canvas (exit the workflow and open it again) can clear transient state issues—this is similar to advice given for nodes stuck waiting for events. It can help in reloading the full configuration.

5. Review Recent Updates or Changes
   Even though you updated the Execute Workflow node from 1.1 to 1.2, verify if there are additional changes in the overall workflow or subworkflow that might cause a property (like “disabled”) to be missing. This could be tied to differences in how legacy workflows are interpreted in the latest version.

---

Summary

The error is likely occurring because one part of your multi-workflow setup isn’t executing as expected—resulting in a missing node property when the execution engine attempts to read it. Reviewing the execution order, adding checks for node execution, and ensuring that your subworkflow setups are in alignment with the current n8n version should help resolve the issue.

If you continue to experience difficulties, please verify the complete wiring of your nodes and consider isolating parts of the workflow to identify the exact node or configuration that is not providing the expected output.