Import fails on free tier because of customDomains

[iinuwa]

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

There is a TypeError thrown when importing into a free tier tenant on customDomains. This is similar to #542. The issue is that calculateChanges does not expect existing to be null. Changing this to return an empty array [] on error would fix the issue.

2023-02-21T20:46:38.651Z - debug: Start processChanges for logStreams [delete:0] [update:0], [create:0], [conflicts:0]
2023-02-21T20:46:38.987Z - error: Problem running command import during stage processChanges when processing type customDomains
2023-02-21T20:46:38.988Z - error: existing is not iterable
2023-02-21T20:46:38.988Z - debug: TypeError: existing is not iterable
    at calculateChanges (/home/iinuwa/.nvm/versions/node/v18.14.0/lib/node_modules/auth0-deploy-cli/lib/tools/calculateChanges.js:70:19)
    at CustomDomainsHadnler.<anonymous> (/home/iinuwa/.nvm/versions/node/v18.14.0/lib/node_modules/auth0-deploy-cli/lib/tools/auth0/handlers/default.js:99:60)
    at Generator.next (<anonymous>)
    at fulfilled (/home/iinuwa/.nvm/versions/node/v18.14.0/lib/node_modules/auth0-deploy-cli/lib/tools/auth0/handlers/default.js:5:58)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)

Expectation

The tool imports data into a free tier, ignoring features that are not provided in free tier subscriptions.

Reproduction

1. Given a free tier tenant
2. when a0deploy import runs
3. then it returns an error

Deploy CLI version

7.16.1

Node version

18.14.0

[iinuwa]

@willvedd, I think you might be familiar with this; would you be able to take a look at this? This is preventing my org from be able to use this CLI in our CI pipelines.

[willvedd]

@iinuwa Can you provide more information about this? Specifically, are you only working within that single tenant or across multiple tenants (some free, some paid)?

My initial thoughts is that it isn't necessarily correct to assert an empty set of custom domains in those instances because if you're working in a multi-tenant context, it would suggest to the system that you'd want to delete those custom domains. Returning as null is a very intentional decision that plays into the patterns of the tool. I think a more suitable solution would be to prevent null assets from being introduced in the diff'ing algorithm.

In the meantime, you're welcome to work-around this issue by excluding custom domains from the purview of the tool: https://github.com/auth0/auth0-deploy-cli/blob/master/docs/configuring-the-deploy-cli.md#auth0_excluded.

Ex: "AUTH0_EXCLUDED": ["customDomains"]

[iinuwa]

Can you provide more information about this? Specifically, are you only working within that single tenant or across multiple tenants (some free, some paid)?

Yes, our non-production tenants are free-tier, while our production tenant is paid.

In the meantime, you're welcome to work-around this issue by excluding custom domains from the purview of the tool: https://github.com/auth0/auth0-deploy-cli/blob/master/docs/configuring-the-deploy-cli.md#auth0_excluded.

Ex: "AUTH0_EXCLUDED": ["customDomains"]

Oh, I didn't realize that would work here. Just tested, and that works for me. Thank you!

Returning as null is a very intentional decision that plays into the patterns of the tool. I think a more suitable solution would be to prevent null assets from being introduced in the diff'ing algorithm.

Yeah, that makes sense. Documenting the workaround above would be helpful, but this would be a more robust solution.

[willvedd]

I ran into this same issue while fixing #811 and have released a fix in 7.17.7.

Please note, however, that this occurs when the target tenant does not support custom domains, often because of tier. So the aforementioned fix will only prevent runtime errors, but you will still be prevented from managing custom domains if your tenant does not support it. This is still better though because you will be presented with a human-readable API error instead of the above existing is not iterable error.

Thanks for your patience!