Main workflow does not proceed to Code node after sub-workflow with Wait node resumes

Questions
1

Describe the problem/error/question

I’m experiencing an issue when a main workflow calls a sub-workflow that contains a Wait node, and then tries to execute a Code node after the sub-workflow call.

If the sub-workflow includes a Wait (Webhook call) node, the execution enters an infinite “Running” state and never proceeds to the next Code node.

As a result, the main workflow remains stuck in the running state indefinitely.

The execution flow behaves as follows:

  • The main workflow triggers the sub-workflow

  • The sub-workflow reaches the Wait (Webhook) node and pauses as expected

  • The webhook is called successfully and the sub-workflow resumes

  • According to debug logs, the sub-workflow finishes successfully

  • However, the main workflow does not continue to the next Code node

  • The main workflow remains stuck in an infinite “Running” state

This issue only occurs when n8n is installed via the Helm chart(GitHub - 8gears/n8n-helm-chart: A Kubernetes Helm chart for n8n - a workflow automation tool. Easily automate tasks across different services on self hosted onKubernetes).

The same workflows work correctly in n8n Cloud and in a single-node Docker installation (following the official Docker setup guide).

What is the error message (if any)?

There is no explicit error message shown in the UI or logs.

The execution simply stays in the Running state.

main workflow

image
image3054×736 154 KB

sub workflow

image
image3034×990 332 KB

Please share your workflow

main workflow

subworkflow

Share the output returned by the last node

NA

Information on your n8n setup

values.yaml

---
# Override name to avoid N8N_PORT env var conflict with Kubernetes service discovery
nameOverride: "n8n-app"

_shared_config:
  hostname: &hostname host
  url: &url https://host

image:
  repository: n8nio/n8n
  tag: 2.3.6
  pullPolicy: Always
imagePullSecrets:
  - name: 8gears-registry-n8n

main:
  config:
    n8n:
      editor_base_url: *url
    executions_mode: queue
    db:
      type: postgresdb
      postgresdb:
        host: host
        port: port
        database: db
        user: user
        pool:
          size: 10
        ssl:
          enabled: true
          reject_Unauthorized: false
    webhook_url: *url
    queue:
      health:
        check:
          active: true
      bull:
        redis:
          host: n8n-valkey
          port: 6379
  secret:
    n8n:
      encryption_key: "key"
  extraEnv: &extraEnv
    DB_POSTGRESDB_PASSWORD:
      valueFrom:
        secretKeyRef:
          name: name
          key: key
  resources:
    limits:
      memory: 1Gi
    requests:
      memory: 256Mi
      cpu: 100m

worker:
  enabled: true
  replicaCount: 1
  extraEnv: *extraEnv
  resources:
    limits:
      memory: 1Gi
    requests:
      memory: 256Mi
      cpu: 100m

webhook:
  enabled: true
  replicaCount: 1
  extraEnv: *extraEnv
  resources:
    limits:
      memory: 1Gi
    requests:
      memory: 256Mi
      cpu: 100m

valkey:
  enabled: true
  replicaCount: 1
  auth:
    enabled: false
  dataStorage:
    enabled: false
  resources:
    requests:
      memory: 256Mi
      cpu: 100m
2

The issue you’re encountering with the Helm chart installation and the Wait node within a sub-workflow is a known problem. It seems the main workflow isn’t resuming correctly after the sub-workflow completes, leading to the “Running” state. Since it works in n8n Cloud and Docker, the problem is likely specific to the Helm chart setup. You might want to check the n8n Helm chart’s documentation or raise an issue on its GitHub repository to see if there’s a workaround or fix available.

3

Thanks for the clarification and for helping identify the root cause. This was very helpful!

1 Like
4

Did it fix it?

If it didn’t, let me know what errored. If it did help, feel free to mark one of our replies as the solution.

Enjoy your day! Let me know if you have any more issues!