Bug: Airtable with Huge Numbers of Single/Multi-Select Options Causes Sluggish n8n UI Performance

[dkindlund]

Bug Description

We have an Airtable base with both single-select and multi-select fields. These options can have over 100+ possible values. When creating a corresponding Airtable Create Node in n8n, n8n tries to be "smart" and store ALL 100+ possible values PER FIELD in EVERY copy of the corresponding node!

This causes huge browser UI performance issues with any sizeable n8n workflow -- to the point where clicking on certain other nodes becomes super sluggish. I believe this is because when n8n's "autocomplete" logic is loading, it dynamically POLLS every field, every option, in EVERY node -- every time you click to open ANY node! It's extremely laggy.

Example:
Instead of storing ALL the options within the node's JSON like:

            {
              "id": "Field With Very Many Options",
              "displayName": "Field With Very Many Options",
              "required": false,
              "defaultMatch": false,
              "canBeUsedToMatch": true,
              "display": true,
              "type": "array",
              "options": [
                {
                  "name": "Mandrill",
                  "value": "Mandrill"
                },
...

We can DRASTICALLY speed up performance if we switch this portion of the JSON field to be represented as a type STRING instead of type ARRAY, like so:

            {
              "id": "Field With Very Many Options",
              "displayName": "Field With Very Many Options",
              "required": false,
              "defaultMatch": false,
              "canBeUsedToMatch": true,
              "display": true,
              "type": "string",
              "readOnly": false,
              "removed": true
            },

I've attached two versions of a sample workflow which illustrates my point:

"Very_Slow.json" is about 2MB (!) in size and stores ALL the values locally.
"Much_Faster.json" is about 230K in size and treats all of these large arrays as just type string instead.

Much_Faster.json
Very_Slow.json

To Reproduce

1. Load up the "Very_Slow.json" into a new workflow
2. Try to open the Slack node and all the other Airtable nodes
3. Witness just how sluggish the browser UI performance is
4. Next, load up the "Much_Faster.json" into a new workflow
5. Witness how just much FASTER the browser UI performance is

Expected behavior

When polling Airtable field schemas, if the number of options exceed like 20+, then treat the field as type STRING and not type ARRAY and don't bother to store ALL the options.

Otherwise, you can't really create any sort of complex n8n automation using multiple Airtable nodes -- because the UI is way too SLOW.

By the way, this is likely NOT just an Airtable-specific ISSUE. I venture a guess that anytime n8n attempts to poll MANY options to store as an array type field across other nodes, the SAME performance issues will exist!

Therefore, this auto-type conversion from ARRAY to STRING likely needs to be applied to any node type (not just Airtable nodes).

Please let me know if this makes sense. Thanks!

Operating System

Google Cloud Run

n8n Version

1.39.1

Node.js Version

18.16

Database

PostgreSQL

Execution mode

main (default)

[Joffcom]

Hey @dkindlund,

Thanks for the report, I have created NODE-1340 as the internal ticket to look into this.