In Queue mode sub Workflow can't execute

Hi, I have a strange issue in queue mode only (1 worker with one main) :

If I use gmail trigger, and execute directly a sub workflow it works, but if I call the full workflow below it fails!

Here is the error

[SubworkflowPolicyChecker] Subworkflow execution denied
n8n worker is now ready

  • Version: 1.63.4
  • Concurrency: 2

    [JobProcessor] Starting job 69 (execution 1212)
    Error: The sub-workflow (J7gXMgGROfKy2PuF) cannot be called by this workflow

I’m on debian 12

Here is my docker compose config:

version: "3"

services:
  n8n:
    image: n8nio/n8n
    container_name: n8n           # Name the container
    ports:
      - "127.0.0.1:5678:5678"               # Expose port 5678 to the host
    environment:
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_DATABASE=${N8N_DB_POSTGRESDB}
      - DB_POSTGRESDB_USER=${N8N_DB_POSTGRESDB_USER}
      - DB_POSTGRESDB_PASSWORD=${N8N_DB_POSTGRESDB_PASSWORD}
      - EXECUTIONS_MODE=queue          # Utilisation de Redis pour les files d'attente
      - QUEUE_BULL_REDIS_HOST=redis    # Lien avec Redis
      - QUEUE_BULL_REDIS_PORT=6379
      - N8N_LOG_LEVEL=${N8N_LOG_LEVEL}       # Set log level to debug
      - N8N_BASIC_AUTH_ACTIVE=true # Enable basic auth
      - N8N_BASIC_AUTH_USER=${N8N_BASIC_USER} # Set basic auth username
      - N8N_BASIC_AUTH_PASSWORD=${N8N_BASIC_PASSWORD} # Set basic auth password
      - N8N_HOST=${DOMAIN_NAME} # Set the host for n8n
      - N8N_PORT=5678             # Set n8n port to 5678
      - N8N_PROTOCOL=https        # Use HTTPS protocol
      - WEBHOOK_URL=https://${DOMAIN_NAME}/ # Webhook URL
      - GENERIC_TIMEZONE=${GENERIC_TIMEZONE} # Set timezone to Paris
      - NODE_ENV=production        # Set Node environment to production
      - NODE_FUNCTION_ALLOW_EXTERNAL=${N8N_FUNCTION_ALLOW_EXTERNAL}
    volumes:
      - /home/debian/n8n-docker/n8n_data:/home/node/.n8n # Persistent n8n data
      - /home/debian/n8n-docker/local_files:/files       # Volume for local files
    restart: always               # Restart policy to always restart the service
    depends_on:
      - redis
      - postgres

  n8n-worker-1:
    image:  n8nio/n8n
    container_name: n8n-worker-1
    depends_on:
      - redis
      - postgres
      - n8n
    environment:
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - EXECUTIONS_MODE=queue
      - QUEUE_BULL_REDIS_HOST=redis
      - QUEUE_BULL_REDIS_PORT=6379
      - DB_POSTGRESDB_DATABASE=${N8N_DB_POSTGRESDB}
      - DB_POSTGRESDB_USER=${N8N_DB_POSTGRESDB_USER}
      - DB_POSTGRESDB_PASSWORD=${N8N_DB_POSTGRESDB_PASSWORD}
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_PORT=5432
      - DB_TYPE=postgresdb
    command: ["worker", "--concurrency=2"]
    volumes:
      - /home/debian/n8n-docker/n8n_data:/home/node/.n8n # Persistent n8n data
      - /home/debian/n8n-docker/local_files:/files       # Volume for local files
    restart: always

  postgres:
    image: postgres:15.1
    ports:
      - "127.0.0.1:5432:5432"   # Expose le port 5432 sur l'hôte
    environment:
      - POSTGRES_USER=${N8N_DB_POSTGRESDB_USER}
      - POSTGRES_PASSWORD=${N8N_DB_POSTGRESDB_PASSWORD}
      - POSTGRES_DB=${N8N_DB_POSTGRESDB}
    volumes:
      - ./postgres_data:/var/lib/postgresql/data
    restart: always               # Restart policy to always restart the service

  redis:
    image: redis:6
    ports:
      - "127.0.0.1:6379:6379"
    volumes:
      - ./redis_data:/data
    restart: always               # Restart policy to always restart the service

If you open the subworkflow node in the failed execution, you should see the full error message with the reason for the denial. Is that not showing for you?

"Workflow execution had an error

The sub-workflow (J7gXMgGROfKy2PuF) cannot be called by this workflow"
No more than in logs given !

I have only one user, I’ve checked in DB for same user!
I think it’s something like a different thread stuff linked to LLM that introduce it (as opposed to direct call that is working)

Aside from the message The sub-workflow (ID) cannot be called by this workflow in the toast, if you open the Execute Workflow node in your parent workflow, you should see the reason below the error message. Does this not show for you?

As mentioned there, you might need to adjust which workflows the subworkflow may be called by, e.g. if you have set it to No other workflows

What you said make no sense to me.

1 - I can call the sub workflow if not calling it after LLM. That mean I have the permission !
2 - I have not the setting to restrict workflow permission (self hosted community edition).
3- The workflow is queued and marked as success in the main workflow !

Checking “wait for reply” in the caller workflow, I have this detailed error now. Please help me (I have no option in setting of the child workflow to change permissions):

The sub-workflow (J7gXMgGROfKy2PuF) cannot be called by this workflow

The sub-workflow you’re trying to execute limits which workflows it can be called by. You will need John to update the sub-workflow (J7gXMgGROfKy2PuF) settings to allow this workflow to call it.

Error details

n8n version 1.64.3 (Self Hosted)

Stack trace

SubworkflowPolicyDenialError: The sub-workflow (J7gXMgGROfKy2PuF) cannot be called by this workflow at SubworkflowPolicyChecker.check (/usr/local/lib/node_modules/n8n/dist/subworkflows/subworkflow-policy-checker.service.js:52:15) at processTicksAndRejections (node:internal/process/task_queues:95:5) at Object.executeWorkflow (/usr/local/lib/node_modules/n8n/dist/workflow-execute-additional-data.js:564:9) at Object.executeWorkflow (/usr/local/lib/node_modules/n8n/node_modules/n8n-core/dist/NodeExecuteFunctions.js:2320:24) at Object.execute (/usr/local/lib/node_modules/n8n/node_modules/n8n-nodes-base/dist/nodes/ExecuteWorkflow/ExecuteWorkflow.node.js:236:40) at Workflow.runNode (/usr/local/lib/node_modules/n8n/node_modules/n8n-workflow/dist/Workflow.js:722:19) at /usr/local/lib/node_modules/n8n/node_modules/n8n-core/dist/WorkflowExecute.js:711:51 at /usr/local/lib/node_modules/n8n/node_modules/n8n-core/dist/WorkflowExecute.js:1141:20


Docs

Note on using an expression here: if this node is set to run once with all items, they will all be sent to the same workflow. That workflow’s ID will be calculated by evaluating the expression for the first input item.

Any data you pass into this node will be output by the Execute Workflow Trigger. More info

Mode
Options
Wait For Sub-Workflow Completion

I have a self-hosted - license: community.
According to documentation:
“* This workflow can be called by: choose whether other workflow can call this workflow. Requires Workflow sharing.”

So sharing setting is “Available on Pro and Enterprise Cloud plans, and Enterprise self-hosted plans.”

But I don’t need extra settings of sharing I only need the workflow to be executed by all!

So it’s definitively a bug or you not mentionning that the queue mode is not available in community version!

Regards

Hi,
I’ve made a fully qualified ticket now (see below)
Thanks for your support

@bluestart83 Did you manage to solve the problem?
I’m having the same issue you described.
When I run n8n in Queue mode, it gives this error.

I am the owner of all workflows, but I receive this error.

n8n version 1.71.3 (Self Hosted)

image

No I’ve removed workers, praying for a Fix one day! ^^*
May be now as we are at least two in that bug, they’ll have a look at it?

Regards

I think it’s not a bug. In my case, my redis had old projects cached. Those projects are compared when the sub-workflow execution policy is workflowsFromSameOwner, which is the default value.

To solve this issue, I just deleted the workflow-project key from redis. The full command is DEL n8n:cache:workflow-project.

Another way of solving this is setting an explicit policy through configuration. You can set N8N_WORKFLOW_CALLER_POLICY_DEFAULT_OPTION to any.

In the source code, the validation happens here.

First, it loads the sub-workflow execution policy (here). The default value is workflowsFromSameOwner, see here. In my case, it loaded the default policy, so it checked if the workflows belong to the same ‘owner’. Owner, according to the code here, is the projectId.

The projectId is cached per workflow (see here). Since I created different projects (by deleting the db over and over again XD) and always imported the same workflows, the cache was invalid. It mapped the workflowId to the wrong projectId thus failing the workflowsFromSameOwner policy.

1 Like