-
Notifications
You must be signed in to change notification settings - Fork 4.3k
[ManagedIO] Fail expansion when encountering extra or unknown configuration #34525
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
[ManagedIO] Fail expansion when encountering extra or unknown configuration #34525
Conversation
Checks are failing. Will not request review until checks are succeeding. If you'd like to override that behavior, comment |
msg += " Missing required fields: " + missingRequiredFields + "."; | ||
} | ||
if (!userParams.isEmpty()) { | ||
msg += " Contains unknown fields: " + userParams + "."; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I remember when I worked with SchemaIO I encountered similar scenario due to Beam version mismatch between Python / and expansion service. This could be a valid use case on dev, e.g. python code is presubmit and java expansion service not yet regenerated.
Could this happen in managed transform also? Saying user is using a newer version of Beam with added configurations while managed backend isn't rollout out
if so shall we issue warning here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After some offline conversations, we settled for a new API .skipConfigValidation()
that will let users opt out if they need to
Assigning reviewers. If you would like to opt out of this review, comment R: @claudevdm for label python. Available commands:
The PR bot will only process comments in the main thread (not review comments). |
We are currently letting anything come and go, but we should be more strict and only allow configuration that is actually available for the underlying transform