- Notifications
You must be signed in to change notification settings - Fork 25.6k
Apply more strict parsing of actions in bulk API #115923
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
Apply more strict parsing of actions in bulk API #115923
Conversation
Previously, the following classes of malformed input were deprecated but not rejected in the action lines of the a bulk request: - Missing closing brace; - Additional keys after the action (which were ignored); - Additional data after the closing brace (which was ignored). They will now be considered errors and rejected. The existing behaviour is preserved in v8 compatibility mode. (N.B. The deprecation warnings were added in 8.1. The normal guidance to deprecate for a whole major version before removing does not apply here, since this was never a supported API feature. There is a risk to the lenient approach since it results in input being ignored, which is likely not the user's intention.)
| Hi @PeteGillinElastic, I've created a changelog YAML for you. Note that since this PR is labelled |
| Pinging @elastic/es-data-management (Team:Data Management) |
| The |
dakrone left a comment
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.
LGTM, I left one comment. Thanks Pete!
docs/changelog/115923.yaml Outdated
| Previously, the following classes of malformed input were deprecated but not rejected in the action lines of the a | ||
| bulk request: missing closing brace; additional keys after the action (which were ignored); additional data after | ||
| the closing brace (which was ignored). They will now be considered errors and rejected. | ||
| impact: Users must provide well-formed input when using the bulk API |
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.
Can you mention that rest API compatibility can be used in this case, if they need the previous behavior?
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.
Good call. I'm adding "They can request REST API compatibility with v8 to get the previous behaviour back as an interim measure."
Previously, the following classes of malformed input were deprecated but not rejected in the action lines of the a bulk request: - Missing closing brace; - Additional keys after the action (which were ignored); - Additional data after the closing brace (which was ignored). They will now be considered errors and rejected. The existing behaviour is preserved in v8 compatibility mode. (N.B. The deprecation warnings were added in 8.1. The normal guidance to deprecate for a whole major version before removing does not apply here, since this was never a supported API feature. There is a risk to the lenient approach since it results in input being ignored, which is likely not the user's intention.)
| @PeteGillinElastic is this PR relevant to the serverless changelog? [FYI this question is based on 9.0 breaking changes] |
I think this depends on the policy for the serverless changelog. Previously, we issued a warning on this class of malformed input but ignored it; now, we reject it. It would only break serverless users if they'd been writing malformed input and ignoring the warnings. Also, this change was made before serverless GA. |
Previously, the following classes of malformed input were deprecated but not rejected in the action lines of the a bulk request:
They will now be considered errors and rejected.
The existing behaviour is preserved in v8 compatibility mode.
(N.B. The deprecation warnings were added in 8.1. The normal guidance to deprecate for a whole major version before removing does not apply here, since this was never a supported API feature. There is a risk to the lenient approach since it results in input being ignored, which is likely not the user's intention.)