"Error trigger" not working anymore

Hello!

Problem: The ERROR trigger doesn’t always activate 100% of the time, which is strange because some workflows, consistently the same ones, are still able to activate the ERROR trigger. We are using the 1.22.6 self-hosted version, but the issue was already present in version 1.21.1.

I attempted to reconstruct the logic from the ground up with two new workflows:

  1. An error workflow named “error bis” containing only the ERROR trigger (along with a webhook for activation).
  1. An error workflow to try to trigger errors:

I confirm that I have connected workflow settings errors to “error bis”:

But even if I see an error in executions:
image

… the error didn’t trigger the “error bis” workflow:
image

Successful executions you see here are, as mentioned above, workflows that are still capable of triggering errors.

Information on your n8n setup

  • n8n version: 1.22.6
  • self-hosted mode on aws with Fargate (docker)
    • using RDS Postgres and EFS for storing n8n data

Thank you for your help!

It looks like your topic is missing some important information. Could you provide the following if applicable.

  • n8n version:
  • Database (default: SQLite):
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app):
  • Operating system:

Sorry to hear that you have problems.

I wonder if there is maybe a misunderstanding how it works, because I just tested and for me everything works correctly.

So first important to mention that Error Workflows do not have to get activated, so the Webhook-Node is not required. All that is needed is that the Workflow is set es Error Workflow and it contains an Error Trigger Node.

Error Workflows do only get triggered in production executions, not manual executions. Do you test via an active workflow via the production URL?

hey @jan

Than you for your answer!

I removed the webhook from the 1st workflow in my request (the “error” workflow) and deactivated it so we’re on the same page.

Tests I ran were in production: I’m triggering the 2nd workflow (containing the error node) from another tool to be sure it behaves as expected in production. But it doesn’t work.

The weird thing is this setup had been working for a year before I encountered this issue.

1 Like

Hey @theo,

I have just been testing this as well and I have not been able to reproduce it either. Looking at the executions screenshot you have shared that looks like it is for a workflow but I can’t see which workflow. Do you have your error workflow set to log successful executions?

1 Like

hey @Jon ,

Yes it is.

Since it doesn’t appear to be from the current version, could it be from our self-hosted setup? What environment settings should we check in this case?

Thank you,

We have the same issues(

  • n8n version: 1.22.6
  • self-hosted mode on DigitalOcean in queue mode
1 Like

Hi there,

Having the same issue here.

made 2 new workflows to test and is not working still. Started with active webhook and production URL

image

image
image

image
image

  • n8n version: 1.22.5
  • Database (default: SQLite): Postgres
  • n8n EXECUTIONS_PROCESS setting (default: own, main): QUEUE / Main
  • Running n8n via (Docker, npm, n8n cloud, desktop app): Docker
  • Operating system: Ubuntu / Docker standard image
1 Like

I have just done some more testing on our internal n8n instance which is running on 1.24.0 with queue mode and Postgres and I am still not able to reproduce this.

It could be that this is something we have fixed and an upgrade will resolve it, If upgrading doesn’t resolve it having a compose file or similar that reproduces the issue would be very handy.

1 Like

issue persists in 1.23 but is solved in 1.24

2 Likes

That is good to hear, Thanks for checking @BramKn :lobster:

1 Like

Hello @Jon

Here our ECS environment settings:

"environment": [
  {
    "name": "DB_TYPE",
    "value": "postgresdb"
  },
  {
    "name": "DB_POSTGRESDB_DATABASE",
    "value": "${rds_n8n_db}"
  },
  {
    "name": "DB_POSTGRESDB_HOST",
    "value": "${rds_n8n_host}"
  },
  {
    "name": "DB_POSTGRESDB_PORT",
    "value": "5432"
  },
  {
    "name": "DB_POSTGRESDB_USER",
    "value": "${rds_n8n_db_user}"
  },
  {
    "name": "DB_POSTGRESDB_SCHEMA",
    "value": "${rds_n8n_db_schema}"
  },
  {
    "name": "DB_POSTGRESDB_PASSWORD",
    "value": "${rds_n8n_db_pwd}"
  },
  {
    "name": "N8N_BASIC_AUTH_ACTIVE",
    "value": "true"
  },
  {
    "name": "N8N_BASIC_AUTH_USER",
    "value": "${n8n_user}"
  },
  {
    "name": "N8N_BASIC_AUTH_PASSWORD",
    "value": "${n8n_pwd}"
  },
  {
    "name": "GENERIC_TIMEZONE",
    "value": "Europe/Berlin"
  },
  {
    "name": "WEBHOOK_URL",
    "value": "${n8n_webhook_url}"
  },
  {
    "name": "N8N_ENCRYPTION_KEY",
    "value": "${n8n_encryption_key}"
  },
  {
    "name": "EXECUTIONS_MODE",
    "value": "queue"
  },
  {
    "name": "QUEUE_BULL_REDIS_HOST",
    "value": "${n8n_redis_hots}"
  },
  {
    "name": "N8N_DISABLE_PRODUCTION_MAIN_PROCESS",
    "value": "false"
  },
  {
    "name": "NODE_OPTIONS",
    "value": "--max-old-space-size=8192"
  },
  {
    "name": "N8N_SKIP_WEBHOOK_DEREGISTRATION_SHUTDOWN",
    "value": "true"
  },
  {
    "name": "EXECUTIONS_DATA_PRUNE_MAX_COUNT",
    "value": "300000"
  },
  {
    "name": "N8N_LOG_FILE_MAXSIZE",
    "value": "32"
  },
  {
      "name": "EXECUTIONS_DATA_SAVE_MANUAL_EXECUTIONS",
      "value": "false"
  }
]

Hi @theo

Try updating your n8n to v 1.24.0

1 Like

Hi!!

The same thing happens here, but I can’t update version. The following error occurs when I try to upgrade the version to 1.24.0 or 1.24.1


Is there any procedure to update the version?

Hi @fullwise

Welcome to the community!

please open a new topic for this. As this error is not related to this topic. It will also help getting eyes on it, as this topic was pretty much solved. and help others in the future that might have the same issue.

2 Likes

Hello!

We just updated our version to 1.24.1 and the error is fixed!

Thank you all for your help :slight_smile:

2 Likes

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.