Airtable Trigger - 429s Are Not Handled as Errors

[dkindlund]

Bug Description

I accidentally set one of my workflows containing an Airtable Trigger to poll every minute, and n8n was unable to correctly report the 429 errors thrown by airtable.com as errors. See details below:

Here's the error in the saved workflow:

Here's the actual bug -- n8n is reporting the workflow status as Unknown instead of Failed:

To Reproduce

1. Create an n8n workflow containing an Airtable Trigger
2. Set the Trigger to poll every minute
3. Wait for 429 errors thrown by airtable.com
4. See the workflow status show as Unknown instead of Failed

Expected behavior

I'd expect triggers that fail to be recorded as Failed executions rather than Unknown executions.

Operating System

Google Cloud Run

n8n Version

1.30.1

Node.js Version

18.10

Database

PostgreSQL

Execution mode

main (default)

[Joffcom]

Hey @dkindlund,

That sounds like a reasonable request, I have created NODE-1217 to look into this in the future. One of the things I want to do at some point is change the node to use webhooks instead which then won't have the same API limits but that probably won't happen soon.

[dkindlund]

Also, the information sent to the Error Workflow for these types of errors is really, really sparse:

[
  {
    "trigger": {
      "error": {
        "message": "The service is receiving too many requests from you",
        "timestamp": 1709722480345,
        "name": "NodeApiError",
        "description": "429 - {} - 429 - {}",
        "context": {},
        "cause": {
          "message": "429 - {}",
          "name": "AxiosError",
          "stack": "AxiosError: Request failed with status code 429\n    at settle (/usr/local/lib/node_modules/n8n/node_modules/axios/lib/core/settle.js:19:12)\n    at IncomingMessage.handleStreamEnd (/usr/local/lib/node_modules/n8n/node_modules/axios/lib/adapters/http.js:589:11)\n    at IncomingMessage.emit (node:events:529:35)\n    at IncomingMessage.emit (node:domain:489:12)\n    at endReadableNT (node:internal/streams/readable:1400:12)\n    at processTicksAndRejections (node:internal/process/task_queues:82:21)\n    at Axios.request (/usr/local/lib/node_modules/n8n/node_modules/axios/lib/core/Axios.js:45:41)\n    at processTicksAndRejections (node:internal/process/task_queues:95:5)\n    at requestFn (/usr/local/lib/node_modules/n8n/node_modules/n8n-core/dist/NodeExecuteFunctions.js:563:33)\n    at proxyRequestToAxios (/usr/local/lib/node_modules/n8n/node_modules/n8n-core/dist/NodeExecuteFunctions.js:566:26)\n    at Object.requestWithAuthentication (/usr/local/lib/node_modules/n8n/node_modules/n8n-core/dist/NodeExecuteFunctions.js:1231:16)\n    at Object.requestWithAuthentication (/usr/local/lib/node_modules/n8n/node_modules/n8n-core/dist/NodeExecuteFunctions.js:1944:20)\n    at Object.apiRequest (/usr/local/lib/node_modules/n8n/node_modules/n8n-nodes-base/dist/nodes/Airtable/v1/GenericFunctions.js:22:12)\n    at Object.apiRequestAllItems (/usr/local/lib/node_modules/n8n/node_modules/n8n-nodes-base/dist/nodes/Airtable/v1/GenericFunctions.js:33:24)\n    at Object.poll (/usr/local/lib/node_modules/n8n/node_modules/n8n-nodes-base/dist/nodes/Airtable/AirtableTrigger.node.js:252:29)\n    at Workflow.runPoll (/usr/local/lib/node_modules/n8n/node_modules/n8n-workflow/dist/Workflow.js:653:16)",
          "code": "ERR_BAD_REQUEST",
          "status": 429
        }
      },
      "mode": "trigger"
    },
    "workflow": {
      "id": "fL6v1q2gYPc9WTqR",
      "name": "Auto - Find Workspaces That Need Top Daily Advice Updated"
    }
  }
]

For example, I'm not seeing:

1. The Execution ID in this JSON
2. A link to the URL for the Execution ID mapping this error
3. The name of the last node executed
4. What the execution mode was

In fact, when I compare these errors to every other type of error thrown, the JSON struction appears vastly different -- here's an example of the "normal" structure:

[
  {
    "execution": {
      "id": "3391",
      "url": "https://XXXREDACTEDXXX/workflow/4lDpqjQQ0lHTd3D6/executions/3391",
      "error": {
        "level": "error",
        "tags": {},
        "context": {
          "runIndex": 0,
          "itemIndex": 0,
          "parameter": "text"
        },
        "functionality": "regular",
        "name": "ExpressionError",
        "timestamp": 1709407830902,
        "message": "no data, execute \"Webhook\" node first",
        "stack": "ExpressionError: no data, execute \"Webhook\" node first\n    at createExpressionError (/usr/local/lib/node_modules/n8n/node_modules/n8n-workflow/dist/WorkflowDataProxy.js:468:20)\n    at Object.get (/usr/local/lib/node_modules/n8n/node_modules/n8n-workflow/dist/WorkflowDataProxy.js:685:35)\n    at Proxy.eval (eval at getFunction (/usr/local/lib/node_modules/n8n/node_modules/@n8n/tournament/dist/index.js:24:22), <anonymous>:6:54)\n    at Tournament.execute (/usr/local/lib/node_modules/n8n/node_modules/@n8n/tournament/dist/index.js:33:19)\n    at evaluateExpression (/usr/local/lib/node_modules/n8n/node_modules/n8n-workflow/dist/ExpressionEvaluatorProxy.js:110:16)\n    at Expression.renderExpression (/usr/local/lib/node_modules/n8n/node_modules/n8n-workflow/dist/Expression.js:219:70)\n    at Expression.resolveSimpleParameterValue (/usr/local/lib/node_modules/n8n/node_modules/n8n-workflow/dist/Expression.js:197:34)\n    at Expression.getParameterValue (/usr/local/lib/node_modules/n8n/node_modules/n8n-workflow/dist/Expression.js:281:25)\n    at getNodeParameter (/usr/local/lib/node_modules/n8n/node_modules/n8n-core/dist/NodeExecuteFunctions.js:1521:42)\n    at Object.getNodeParameter (/usr/local/lib/node_modules/n8n/node_modules/n8n-core/dist/NodeExecuteFunctions.js:2190:24)"
      },
      "lastNodeExecuted": "Basic LLM Chain",
      "mode": "integrated"
    },
    "workflow": {
      "id": "4lDpqjQQ0lHTd3D6",
      "name": "Auto - LLM Wrapper"
    }
  }
]

^ Can we please have just have a single, standard JSON structure for all different types of errors thrown for the Error Workflows handle?

[Joffcom]

The problem is we have different error types for a reason, we are working on changing the error output in the UI but this won’t change that there are different types of errors that have different fields.

If you want to propose a solution to this though we are more than happy for a feature request to be created on the support forum.