Help Needed: Persistent "Cannot read properties of null" & Worker Crashes in Docker Swarm Setup

Questions
1

Hello, n8n community!

I’m facing a persistent issue with my self-hosted n8n setup and I’ve hit a wall after extensive troubleshooting. I’m hoping someone here might have encountered something similar or can spot what I’m missing.

The Core Problem: When I click on any past execution in the n8n UI, it gets stuck on an infinite “Loading” spinner and eventually shows the error: Problem loading execution: Cannot read properties of null (reading 'data'). This seems to be caused by instability in the backend, as the n8n services are constantly crashing and restarting.

My Environment

  • n8n Version: 1.14.3 (specified in the compose file, though logs have sometimes shown 1.15.2 after a restart, which is part of the mystery).

  • Deployment: Docker Swarm on a single-node VPS, managed via Portainer and SSH.

  • VPS Specs: Dedicated Server (2 vCPU, 8 GB RAM, 80 GB SSD).

  • Core Services: n8n (editor, worker, webhook processes), Traefik as a reverse proxy, PostgreSQL for the database, and Redis for queuing.

  • n8n Execution Mode: queue

Summary of Troubleshooting Steps Taken

We’ve gone through a methodical process to diagnose and fix the issue, but the root error persists. Here is what we’ve done:

  • Upgraded Server Resources: The initial server was smaller. I upgraded to the current specs (8GB RAM, 2 dedicated vCPUs) to rule out resource starvation. The issue remained.

  • Optimized Docker Resource Allocation: We updated the docker-compose.yml file to include proper resource reservations and limits for all n8n services, ensuring they could use the new server’s power.

  • Stabilized Internal Docker DNS: The logs initially showed getaddrinfo ENOTFOUND errors for Postgres and Redis. We fixed this by adding a dns: [8.8.8.8] block to all n8n services in the compose file. This error is now gone.

  • Addressed ‘Trust Proxy’ Error: After the initial fixes, the logs revealed a new persistent error. We tried to fix this by adding - N8N_TRUST_PROXY=true to the environment variables for all n8n services.

  • Forced a Clean Stack Redeployment: We suspected that Portainer might have been using a cached or “ghost” configuration. To fix this, we performed a full reset via SSH:

    • Verified the master compose file (/root/n8n.yaml) was 100% correct.

    • Completely removed the stack with docker stack rm n8n.

    • Waited for all services to be removed.

    • Performed a clean deploy with docker stack deploy -c /root/n8n.yaml n8n.

Result: Incredibly, even after the full reset from a verified file, the exact same errors appear in the logs upon startup.

Key Errors We’re Seeing in the Logs

The n8n_editor and n8n_worker logs consistently show this pattern: the service starts, runs for a short while, and then crashes/restarts.

1 - The Persistent ValidationError (The main clue):

ValidationError: The 'X-Forwarded-For' header is set but the Express 'trust proxy' setting is false (default). This could indicate a misconfiguration which would prevent express-rate-limit from accurately identifying users.

This error appears immediately on startup, even though N8N_TRUST_PROXY=true is in our compose file.

2 - The Consequence (Unclean Shutdowns):

Received SIGTERM. Shutting down... Failed to shutdown gracefully

This indicates the processes are crashing, which is likely corrupting execution data and leading to the UI error.

My Question for the Community

The core mystery is: Why would a Docker Swarm service completely ignore an environment variable (N8N_TRUST_PROXY=true) that is explicitly defined in its compose file, even after a full docker stack rm and a clean redeploy?

It feels like the configuration is coming from somewhere else, but we’ve already tried to eliminate that by using the command line exclusively.

Any ideas, no matter how strange, would be greatly appreciated. I’ve been stuck on this for a while. Thank you!

Update and a key new finding:

I’ve discovered a specific pattern for when the execution fails to load. I will provide screenshots to demonstrate this shortly.

The error occurs consistently in workflows where an agent calls another agent and the flow runs completely. These are the workflows that always get stuck on “Loading” and result in the error “Cannot read null data properties.”

In workflows where the agent doesn’t call the other agent, the workflow displays without error.

Execution ok, agent does not call other agent. When the Trix agent calls the other agent, the execution goes into error|750xauto

Execution ok, agent does not call other agent. When the Trix agent calls the other agent, the execution goes into error

|718xauto