-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Alert params and action config will merge sub attributes on update if not explicitly nulled #67290
Comments
Pinging @elastic/kibana-alerting-services (Team:Alerting Services) |
I didn't realize this would break OCC, I didn't think it would. I thought all we really needed was ESO to support the overwrite option, which ended up requiring support for pre-defined IDs.
We are doing this somewhere else, aren't we? Or maybe we used to, but not anymore? This will make the "ability to search through alert/action params" even harder, but it's still not clear to me that we need ES search through the params. Or a precise one anyway - how well would a text search work through those? Maybe that would work good enough?
This seems unpossible, since we don't really know the shapes of the params. Currently, we only require an object with a
I think this would need to be surfaced all the way through our APIs, so breaks everything today :-). We'd need to come up with special per-alert-type migrations to convert existing alerts.
Yeah, if we do nothing else, adding more doc with big lettering is something we should do. Probably specifying that you can never use
Not sure how introspective config-schema is, but this might work if we can analyze a schema. Alternatively, if there isn't enough introspection available for this, I wonder if we could add some new functionality to config-schema that would either check for |
There's also a 6th option, which is likely the most work, adding support for non-partial updates to saved-objects. I'm not aware of any constraints that would prevent us from adding this capability, but I'll ultimately defer to the @elastic/kibana-platform team on the specifics. |
Note: I was remembering wrong, see comment below ... |
Poked around a little bit - it appears that there isn't an overwrite option for update, but there is one for create. So it seems like SO's only support partial update - in fact, the docs specifically shows a partial update of just the title of an index pattern - https://www.elastic.co/guide/en/kibana/current/saved-objects-api-update.html So, not sure what I was thinking - perhaps we were earlier looking at adding an "overwrite" capability to SO.update()? I do specifically remember there was something involving the issue around using your own id's for ESOs that was going to make this more complicated though. I'm a little surprised we only support partial update of SO's - surprised that this hasn't bitten anyone else yet, trying to "delete" an attribute by setting it to |
Agreed :) |
I'm leaning towards exploring option 3. If it works, we would just require a single drop-in function and the issue would go away.
The way I have it in mind is we don't need to know the shape because we can compare the keys in the two objects. Any key that is missing in the new object, we programatically add a null value. Example:
I'm interested at having an example where using what's described above with recursion wouldn't work. Is there an object shape that wouldn't work with such approach? |
Could this be a problem for clients that mistakenly have If we can get option 3 to work, I'd be happy with it, seems like it should "fix" this, given the caveat above. I haven't given it a lot of thought, not sure if there any tricky parts. |
I'm thinking if this "special" function runs after going through the validator, we should be ok. If it doesn't expect a null, it would fail at the validation stage before we assign one. Also agree it's not guaranteed this approach would work but definitely potential. |
You mean BEFORE going through the validator? But in any case, good point, at any point we want to call this special merge fn, we can afterwards call the validation function just to make sure the resulting shape is still "valid". I guess that's just for update, in which case we'd probably call validate twice - once on the incoming payload, do the merge, then validate again. May be confusing to the callers when they hit the second validation, as the messages would presumably be complaining about nulls they didn't pass in the payload ... Seems like a good approach to try though! Simpler than adding an overwrite capability to SO's :-) |
this is a duplicate of #71995 |
Problem
Relates to #64870
Relates to #50256
If an alert type's params schema doesn't set default values of null to all it's optional properties, it is possible for an alert to fail validation of AAD when running. All someone would have to do is to create an alert with an optional value set, call the update API without the optional value set and the alert will fail running.
The same applies for action type's config schema (and possibly secrets?).
The issue happens with the following index mappings in the Elasticsearch:
The scenario can be reproduced in Elasticsearch by doing the following:
As you can see,
foo.bar
didn't get cleared out after the update, it got merged.Solutions
We would lose OCC (optimistic concurrency control) if there's any version conflicts but would solve the problem by replacing the existing document in elasticsearch (delete then insert). To use this solution, we'll need encrypted saved objects to support this by allowing custom ids.
Doesn't feel right but it would work.
Since we load the alert / action on update, we could write a function that does a diff on these sub properties and sets them as null in the update params when missing.
I noticed the alert's
actions[x].params
attribute doesn't have this problem. There is a possibility that storing alert params and action configs into an array structure would solve this problem and possibly also make them searchable.The params value structure could be something like the following:
This would allow a consistent mapping of
name
andvalue
where value can be enabled: false but won't be impacted by this issue (due to being within an array). This would also require a saved object migration.Maybe there's a way to validate this programatically.
The text was updated successfully, but these errors were encountered: