Organization import with connections crashes with TypeError after v8.23.0 (node-auth0 v4→v5 upgrade)

[ZameerIAM]

Checklist

• I have looked into the README and have not found a suitable solution or answer.
• I have looked into the documentation and have not found a suitable solution or answer.
• I have searched the issues and have not found a suitable solution or answer.
• I have upgraded to the latest version of this tool and the issue still persists.
• I have searched the Auth0 Community forums and have not found a suitable solution or answer.
• I agree to the terms within the Auth0 Code of Conduct.

Description

Organization import with enabled connections crashes with TypeError: Cannot read properties of undefined (reading 'id') on versions 8.23.0 through 8.30.0. Works correctly on v8.20.0.

Error

Problem running command import during stage processChanges when processing type organizations
Problem creating organizations {"name":"example-org","display_name":"Example Org","metadata":{"org_type":"Rep"},"connections":[{"is_signup_enabled":true,"assign_membership_on_login":true,"show_as_button":true,"connection_id":"con_xxxxx"}],"client_grants":[]}
TypeError: Cannot read properties of undefined (reading 'id')

Environment

• Node.js: v23.6.1
• OS: macOS Darwin 25.4.0
• Export format: directory
• M2M app: 251 scopes granted (all org + connection scopes confirmed — not a permissions issue)

Org file structure (minimal reproduction)

{
"name": "example-org",
"display_name": "Example Org",
"metadata": {"org_type": "Rep"},
"connections": [{
"name": "My-Database-Connection",
"is_signup_enabled": true,
"assign_membership_on_login": true,
"show_as_button": true
}],
"client_grants": []
}

No discovery_domains — stripped to isolate the issue. The error is in connection enablement during org creation.

Reproduction

1. Export a tenant with 50+ organizations that have enabled connections
2. Import to a fresh tenant: a0deploy import --config_file config.json --input_file ./export
3. First ~3-6 orgs are created successfully
4. CLI crashes with the TypeError on a subsequent org
5. Re-running creates a few more, then crashes again

Version testing:

8.20.0 → WORKS (all 54 orgs imported in single run)
8.25.0 → FAILS (~3-6 orgs per run then crashes)
8.29.0 → FAILS (~3 orgs per run then crashes)
8.29.2 → FAILS (~3 orgs per run then crashes)
8.30.0 → FAILS (~3 orgs per run then crashes)

Detailed run log (10 runs across 5 versions):

Run 01 | v8.25.0 | 0→6 | +6 | Crashed after 6 orgs
Run 02 | v8.25.0 | 6→9 | +3 | Crashed after 3 orgs
Run 03 | v8.25.0 | 9→12 | +3 | Crashed after 3 orgs
Run 04 | v8.25.0 | 12→15 | +3 | Crashed after 3 orgs
Run 05 | v8.30.0 | 15→15 | +0 | Crashed (org already existed)
Run 06 | v8.30.0 | 15→18 | +3 | Crashed after 3 orgs
Run 07 | v8.29.2 | 18→21 | +3 | Crashed after 3 orgs
Run 08 | v8.29.0 | 21→24 | +3 | Crashed after 3 orgs
Run 09 | v8.25.0 | 24→27 | +6 | Crashed after 6 orgs
Run 10 | v8.20.0 | 27→54 | +27 | SUCCESS — all remaining orgs imported

And add a note above: "Orgs are processed alphabetically. Each run skips existing orgs
and creates new ones until it crashes. The crash occurs on a different org each run —
it's not org-specific."

Root cause analysis

The regression was likely introduced in v8.23.0 which upgraded node-auth0 from v4 to v5
(#1207). The SDK v5 changed response formats (.data wrapper), pagination, and method
signatures for nested resources. The organization handler's connection resolution code
appears to not be fully updated for the v5 response format.

Supporting evidence:

• v8.23.1 fixed race conditions in handler processing (fix: resolve race conditions in processChanges for handlers  #1240) and client grants
  pagination (fix: client grants pagination to use checkpoint and tests #1239) — partial v5 migration fixes
• v8.29.1 fixed enabled_clients pagination for connections — more v5 migration fixes
• v8.29.3 fixed efficiency/reliability of fetching enabled_clients — ongoing fixes
• None of these addressed the org connection resolution path

Additional issue: Trigger bindings silently not applied (ignore as not a big deal but I feel org issue is).

During the same import testing, we observed that action trigger bindings are silently not applied. The CLI creates and deploys actions successfully but the triggers/triggers.json bindings are never processed. No error or warning is logged. This was observed across multiple full import runs on v8.25.0 through v8.30.0.

Workaround

• Use v8.20.0 for organization imports: npm install -g auth0-deploy-cli@8.20.0
• Or use the Auth0 Management API directly for org creation
• For trigger bindings: manually apply via PATCH
  /api/v2/actions/triggers/{triggerId}/bindings

Happy to provide additional details or retest if there's something I may be missing. The v8.20.0 workaround is functional for now.

Expectation

All 54 organizations (in my case) with enabled connections should be imported in a single run without errors — as it works correctly on v8.20.0. The CLI should handle connection name-to-ID resolution reliably regardless of the number of organizations being processed.

Reproduction

1. Export a tenant with 50+ organizations that have enabled connections
2. Import to a fresh tenant: a0deploy import --config_file config.json --input_file ./export
3. First ~3-6 orgs are created successfully
4. CLI crashes with the TypeError on a subsequent org
5. Re-running creates a few more, then crashes again

Deploy CLI version

8.25.0 through 8.30.0 (works on 8.20.0, all on same Node v23.6.1)

Node version

v23.6.1 (note: not in deploy CLI's supported range of ^20.19.0 || ^22.12.0 || ^24.0.0, but v8.20.0 works fine on this same Node version). I can retest on v22 LTS. But the 8.20.0 vs v8.25.0+ difference on the same Node rules it out.

[kushalshit27]

Thank you for reporting this issue! Our team is currently investigating the issue.