Title is wrong, the flag in question is new_universal_login_experience_enabled. Couldn’t submit a post containing a word that long in the title (a frustrating limitation…).
We’re getting the error:
error: Problem running command import during stage processChanges when processing type tenant
error: Payload validation error: 'Additional properties not allowed: new_universal_login_experience_enabled' on property flags (Flags used to change the behavior of this tenant).
info: Please refer to the Auth0 Management API docs for expected payloads: https://auth0.com/docs/api/management/v2
Has the new_universal_login_experience_enabled field been depreciated? I don’t see anything specific in the management API docs. Is this configured purely in the dashboard login_settings now?
2023-06-02T14:16:23.821Z - error: Problem running command import during stage processChanges when processing type tenant
2023-06-02T14:16:23.821Z - error: Payload validation error: 'Additional properties not allowed: new_universal_login_experience_enabled' on property flags (Flags used to change the behavior of this tenant).
2023-06-02T14:16:23.821Z - info: Please refer to the Auth0 Management API docs for expected payloads: https://auth0.com/docs/api/management/v2
npm ERR! code ELIFECYCLE
npm ERR! errno 1
All - This is Will, one of the main contributors for the Auth0 Deploy CLI.
As you’ve discovered, the new_universal_login_experience_enabled flag has been deprecated because that setting is adequately captured elsewhere in the tenant definition. However, other folks may be seeing a similar error message but different flag being referenced. This is because Auth0 is constantly evolving the product and delivering updates, sometimes causing these flags to be suddenly incompatible. I acknowledge that this can be an inconvenience to you and your development process.
As an initial workaround you can safely remove the new_universal_login_experience_enabled property from your tenant resource definition. We will be looking into how we can validate these flags automatically such that this problem doesn’t pop up again.
Thanks everyone for surfacing this issue. I hope this helps!
At a minimum, we need some form of retrospective confirmation over what has been added/changed/removed. If the following page had a changelog, we could validate the flag was intentionally decommissioned.
Hi @will.vedder, are you issuing deprecation notices from a0deploy for things like this? Is it possible to force a0deploy to fail for deprecated config? And/or do you publish JSON schemas we can use to validate the config?
We have a CI step for PRs that a0deploys new config to a sandbox tenant, blocking the PR when it fails to prevent deploying bad config. What happened for us was that you changed this property from deprecated to failing after it passed that sandbox test, but before it was merged, and our CI deployed the assumed-valid config to our dev tenant, breaking auth for dev applications.
Update: Thanks for everyone’s patience here. To recap, this problem stemmed from an undocumented, internally-focused feature flag being deprecated in the API. These flags are used to facilitate backend migrations, opt-in specialized features and generally perform maintenance. The Deploy CLI was managing some of these flags on behalf of the users, so when the removal happened, the above API error occurred.
Resolution: We’ve released a v7.17.4 update to Deploy CLI that actively ignores these internally-focused flags. This will ensure a much higher degree pf compatibility between all tenants, regions, configurations and permutations thereof. This change is also naturally defensive by nature, avoiding issues even if another deprecated flag were to occur. This will have no material impact to your tenants, they will still operate and deploy as expected. If any issues arise, please submit a Github issue to the Deploy CLI repo so we can resolve for you.
Additionally, the removed flag in question was un-removed to maintain backwards compatibility.
Regarding the questions around deprecations and removals, for the vast majority of cases, no breaking changes are introduces into Auth0’s APIs. But as we’ve seen on special occasions, removal of undocumented, internal flags may be performed. We’re reevaluating this practice and looking for ways to improve our tools and API to improve customer outcomes. Deprecations of documented API features are otherwise rare and would be accompanied with abundant communications.
Thanks again for everyone’s patience here. Hope this helps!