version 5.0.0 fails on directory import with Payload validation error
See original GitHub issueDescription
On running a directory import with a directory that used to work prior to v5, we get a failure with the following error:
error: Problem running command import during stage processChanges when processing type pages
error: Payload validation error: 'Additional properties not allowed: url' on property change_password (Change Password page customization).
There is no change_password property anywhere in our directory.
Reproduction
Our directory only includes emails, rules, and pages. Allow deletes is turned off.
Environment
Using latest version 5.0.0.
Issue Analytics
- State:
- Created 3 years ago
- Reactions:8
- Comments:14 (4 by maintainers)
Top Results From Across the Web
Incoming webhook failed validation: | WordPress.org
I'm getting a lot of Incoming webhook failed validation: issues coming in. It's intermittent for example today I had 9 order using stripe…...
Read more >VMware vSphere Lifecycle Manager fails to download patches ...
Attempting to sync updates with vSphere Lifecycle Manager generates an error similar to: An error occurred while downloading depot metadata ...
Read more >Hibernate Validator 8.0.0.Final - Jakarta Bean Validation ...
The validate() method returns a set of ConstraintViolation instances, which you can iterate over in order to see which validation errors ...
Read more >Known Issues and Workarounds in Cloudera Manager 5 | 5.x
Renaming an empty directory on Amazon S3 when a DynamoDB table is used for S3Guard may fail and result in an error. Affected...
Read more >Changelog - webargs 8.2.0 documentation
Failure to validate flask headers would produce error data which contained tuples ... <5.0.0 from webargs import ValidationError def auth_validator(value): ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found

The issue was fixed by the newest version of auth0-source-control-extensions (https://github.com/auth0-extensions/auth0-source-control-extension-tools/releases/tag/v4.1.1). Please re-install the auth0-deploy-cli and it will automatically pull the patched version of auth0-source-control-extensions.
We’re sorry for the inconvenience 🙏
Thanks for confirming 🙇
Here are a little bit more details and how we are preventing these issues to occur again. This project (auth0-deploy-cli) currently has a dependency on auth0-source-control-extension-tools. The version specifier is currently set to
^4.0.7:https://github.com/auth0/auth0-deploy-cli/blob/a6c762addc38e002880419c13c07de434ac3e9e3/package.json#L32
In practice, this means that installing auth0-deploy-cli will pull the latest version of auth0-source-control-extension-tools (including minor bumps). Because we follow semantic versioning, it becomes problematic when we ship new features (minor bumps) to that project and auth0-deploy-cli immediately starts pulling these features. auth0-deploy-cli needs to implement the corresponding handlers for these new features or otherwise we face unexpected conditions like here.
As a measure to solve these kinds of issues in the future, we are switching to using tilde-matching for the version specifier, which will only pull patch-level upgrades to the library. See: https://github.com/auth0/auth0-deploy-cli/pull/252#discussion_r450471794
Thanks again for the report and sorry for the inconvenience