Latest v7.2.1 outputting warnings about client_metadata

Description

When trying to import tenant.yaml file with Auth0 Deploy CLI v7.2.1, we are encountering warnings about client_metadata for “undefined”

The clients still update after the warnings appear, as seen in the example logs below(with debug flag), but it is raising some concerns:

2021-08-23T21:15:21.278Z - warn: Detected that the client_metadata of the following undefined should be emptied. Doing so may be destructive. You can enable deletes by setting ‘AUTH0_ALLOW_DELETE’ to true in the config {“name”:“Test Application”,“client_id”:“siSPR…U1Dh”} 2021-08-23T21:15:21.280Z - debug: Start processChanges for clients [delete:0] [update:1], [create:0], [conflicts:0] 2021-08-23T21:15:21.624Z - debug: Stripping “Test Application” read-only fields [“jwt_configuration.secret_encoded”,“client_id”] 2021-08-23T21:15:23.531Z - info: Updated [clients]: {“name”:“Test Application”,“client_id”:“siSPR…U1Dh”}

The warning appears whether “AUTH0_ALLOW_DELETE” is set to true or false in the config file

Our config.json contains the following:

{
  "AUTH0_DOMAIN": "REDACTED.us.auth0.com",
  "AUTH0_CLIENT_ID": "SJZ......w7",
  "AUTH0_ALLOW_DELETE": true,
  "EXCLUDED_PROPS": {
    "clients": ["client_secret"],
    "connections": ["options.client_secret"]
  }
}

Reproduction

1. a0deploy export config with YAML format (a0deploy export -f yaml -o output/to/directory/. --config_file path/to/config.json)
2. a0deploy import the same exported tenant.yaml + config (a0deploy import --input_file path/to/tenant.yaml --config_file path/to/config.json --debug)

This warning is appearing consistently

[willvedd]

Fixed with v7.4.0. Thanks for bearing with us folks!

[willvedd]

Had a chance to look at this closer. Good news is that the warning is fairly benign, that is, it looks scary but wouldn’t cause any destructive behavior. In fact, as some have noted, the relevant function that deals with diff’ing client metadata doesn’t even respect AUTH0_ALLOW_DELETE, this will need to be fixed in a follow-up PR.

The reason why this error was happening was that we need to treat object properties with special care, especially when determining if a deletion should occur or not. The particular function that performed this diff would see an empty client metadata field proposed and think that something needed to be deleted without also checking to see if the current state of that same property. Or put another way, it was looking to delete something that was never set in the first place. This warning is well intentioned, but the code never accounted for the case of the current state and the proposed state being empty objects. The fix here is to check that they’re both empty and short-circuit.

Hoping that makes sense to folks. I’ll be looking to get this reviewed and then queue up for our next release.