Avoid stale enrich results after policy execution#133752
Avoid stale enrich results after policy execution#133752joegallo merged 7 commits intoelastic:mainfrom
Conversation
|
Pinging @elastic/es-data-management (Team:Data Management) |
|
Hi @joegallo, I've created a changelog YAML for you. |
jbaiera
left a comment
There was a problem hiding this comment.
LGTM, small question about test case
| // TODO Change this to run with security enabled | ||
| // https://github.com/elastic/elasticsearch/issues/75940 |
There was a problem hiding this comment.
Should this new test be updated to run with security? If not, we should make sure to update #75940 with a check list item for this test
There was a problem hiding this comment.
👍, that's fair -- I'll add this one to the checklist for now, but separately take on the task of thinking about making these tests run with security. (edit: done, and promises made publicly #75940 (comment))
docs/changelog/133752.yaml
Outdated
| @@ -0,0 +1,5 @@ | |||
| pr: 133752 | |||
| summary: Fix enrich fails to update when source changes | |||
There was a problem hiding this comment.
Nit: should we rephrase this to make it easier to understand and find for users? Perhaps something like: Avoid stale enrich cache results after policy is re-ran?
|
#133762 is up for the backport (I forgot the dang label!). |
In the course of reviewing #133680, @jbaiera realized that there's an unrelated bug in the
enrichprocessor.The updated logic of the
enrichprocessor from #124099 (released in 9.1.0) captures the project metadata, rather than the project id, which means that it doesn't see changes to the cluster state over time, including updates to the enrich index. As a consequence, executing an enrich policy wouldn't result in changes from the source index being reflected in the results of theenrichprocessor.The fix here is to bind the project id and look up the project metadata.