Hi @ricardo_balako
The error you are encountering, “Cannot read properties of undefined (reading ‘execute’)”, is a classic symptom of a communication breakdown in n8n’s queue mode. Because your workflow functions correctly within the editor but fails in production, the issue is almost certainly not with your workflow logic itself, but rather with how your distributed environment is handling the job. In queue mode, the primary instance sends a task to a separate worker process, and if that worker cannot properly initialize the required node, it crashes before it can even begin the execution.
The most common cause for this is a version mismatch between your primary instance and your worker instance. Even if both appear to be running the latest version, subtle differences in the underlying Docker images can prevent them from communicating correctly. It is essential to ensure that both services are explicitly using the exact same image tag and that you perform a full redeploy of both components simultaneously to ensure they are synchronized.
Another critical factor is the consistency of your environment variables across your infrastructure. Your primary and worker services must share the exact same configuration, particularly regarding the encryption key, database connection details, and Redis settings. If the worker lacks the correct configuration, it may fail to authenticate with your database or Redis, causing the “undefined” error when it tries to retrieve the workflow data it needs to start the job.
You should also verify that your worker service is configured to run specifically as a worker process. In your Easypanel setup, confirm that the command for your worker container is set to worker (e.g., n8n worker). Additionally, setting the environment variable N8N_REINSTALL_MISSING_PACKAGES=true on your worker is a good practice, as it ensures the worker has all the necessary dependencies, such as those required by the AI Agent node, which might be missing in a fresh worker environment.
The fact that the error points to bull (the queue management library) confirms that the failure is happening at the infrastructure level. The best way to get to the bottom of this is to ignore the main n8n logs and focus exclusively on the logs of the worker container at the exact moment you submit the form. These worker-specific logs will often provide the specific reason—such as a connection timeout or a missing dependency—that the job failed to initialize.
If you have verified the versioning, configuration, and logs and the issue persists, you may want to test by setting EXECUTIONS_PROCESS=main on your primary instance as a temporary diagnostic step. While this bypasses the worker infrastructure, it will confirm whether the problem is strictly related to the queue system. If the workflow runs fine in this mode, it confirms that your issue is isolated to the interaction between your primary n8n instance and the worker processes.