-
Notifications
You must be signed in to change notification settings - Fork 8.4k
[Ingest Pipelines] Preserve unknown fields in processors #91146
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
[Ingest Pipelines] Preserve unknown fields in processors #91146
Conversation
Pinging @elastic/es-ui (Team:Elasticsearch UI) |
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.
Changes LGTM. Verified locally. Thanks for the quick turnaround on this!
@elasticmachine merge upstream |
@elasticmachine merge upstream |
@alisonelizabeth , I've realised that this implementation is based on the incorrect premise that fields without values willl still be included in the processor form output - by default the form lib will strip them. The misunderstanding snuck in for me with the I will update this implementation to be more robust. |
…"value" for set and gsub
* This is important for allowing configuration of empty text fields in certain processors that | ||
* remove values from their inputs. | ||
*/ | ||
stripEmptyFields: false, |
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.
This is quite an important change for this fix, it also means we need to add the appropriate serializer for all fields. I tested all forms locally and the LGTM. But it would be good to check them for any unexpected resulting "foo": ""
entries.
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.
@jloleysens I went through and retested all the processors. I found two potential issues -
I think the serializer needs to be fixed for the regex_file
option in the user agent processor. If I do not provide a value for the field, the request looks like:
{
"user_agent": {
"field": "sdf",
"regex_file": ""
}
}
I also noticed for the foreach
processor, I am able to save the form without specifying a processor and the request retains the {}
as the value, which results in an error from ES.
{
"foreach": {
"field": "asdf",
"processor": {}
}
}
@@ -50,15 +51,6 @@ const fieldsConfig: FieldsConfig = { | |||
'xpack.ingestPipelines.pipelineEditor.gsubForm.replacementFieldHelpText', | |||
{ defaultMessage: 'Replacement text for matches.' } | |||
), | |||
validations: [ |
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 wonder if we should add some help text indicating that leaving the input blank will default to an empty string value.
@@ -81,7 +81,7 @@ const fieldsConfig: FieldsConfig = { | |||
lang: { | |||
type: FIELD_TYPES.TEXT, | |||
deserializer: String, | |||
serializer: from.undefinedIfValue('painless'), | |||
serializer: (v: unknown) => (v === 'painless' || v === '' ? undefined : v), |
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.
[nit] I know this wasn't introduced in this PR - but I noticed that if I set the lang
to "painless"
via the ES API, it does retain the value. I think it could be potentially confusing to a user if they add painless
to the text field in the UI and then it is stripped from the request.
@@ -35,15 +28,6 @@ const fieldsConfig: FieldsConfig = { | |||
helpText: i18n.translate('xpack.ingestPipelines.pipelineEditor.setForm.valueFieldHelpText', { | |||
defaultMessage: 'Value for the field.', | |||
}), | |||
validations: [ |
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.
Same comment here about possibly adding some help text
@elasticmachine merge upstream |
Thanks for the review @alisonelizabeth ! I think I have addressed all of your feedback, would you mind taking another look?
I'm going to hold off on this change for now since it is pre-exsting behaviour, I think the error response from ES is also very helpful in guiding users. Let me know what you think! |
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.
Latest code LGTM. Did not test again. I'm fine with holding off on fixing the foreach
behavior.
@elasticmachine merge upstream |
* keep known and unknown options in processor config * added test for preserving unknown fields * refactor form for NOT stripping empty field values, also allow empty "value" for set and gsub * remove unused i18n * fix user agent form serialization, update field help text * remove out of date translation Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
💚 Build SucceededMetrics [docs]Async chunks
History
To update your PR or re-run it, just comment with: |
…1630) * keep known and unknown options in processor config * added test for preserving unknown fields * refactor form for NOT stripping empty field values, also allow empty "value" for set and gsub * remove unused i18n * fix user agent form serialization, update field help text * remove out of date translation Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Summary
After elastic/elasticsearch#65314 was merged we discovered that when editing a processor unknown fields are not returned from the forms in ingest pipelines editor.
This contribution adds logic to pick out the unknown fields and keep them, even after updating a processor.
Also fix #91135
How to test
nginx
cURL request
nginx
pipelinemedia_type
value is still present on the set processorNotes
These changes ensure that unknown values in processor
options
are preserved. We only check for unknown entries at the top-level of theoptions
object; the assumption is that options configuration with nested values do not exist.That is:
Release note
Fixes a small form validation bug that required an input for the set processor value field and gsub processor replacement field. Both fields now accept an empty value to either set a value to an empty string in the case of the set processor and remove any matched text in the case of the gsub processor.
Checklist
Delete any items that are not applicable to this PR.