-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
x-pack/filebeat/input/entityanalytics/provider/azuread: avoid work on unwanted datasets #36753
Conversation
9b8942a
to
99c1b96
Compare
This comment was marked as off-topic.
This comment was marked as off-topic.
99c1b96
to
ace7053
Compare
Pinging @elastic/security-external-integrations (Team:Security-External Integrations) |
wantUsers := p.conf.wantUsers() | ||
wantDevices := p.conf.wantDevices() |
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.
@taylor-swanson I think we can omit these conditions here since the returned values form doFetch
should be empty in the case that. Do you agree?
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.
Yeah it would seem they are redundant in this particular case. I'm trying to think if there is some other edge case, but can't think of anything. doFetch
will return empty an empty set if the dataset is disabled, so we really only need to guard the full sync case.
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
See other comment, but I'm good with removing the wantUsers
/wantDevices
guards in the incremental update case.
wantUsers := p.conf.wantUsers() | ||
wantDevices := p.conf.wantDevices() |
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.
Yeah it would seem they are redundant in this particular case. I'm trying to think if there is some other edge case, but can't think of anything. doFetch
will return empty an empty set if the dataset is disabled, so we really only need to guard the full sync case.
This pull request is now in conflicts. Could you fix it? 🙏
|
… unwanted datasets During full sync the provider may have state from a previous dataset. So in the case that the user has changed dataset from users to devices or vice versa the provider may publish already existing state in the entity graph. This change adds conditional checks to ensure that unwanted dataset records are not published.
ace7053
to
c70e6c7
Compare
… unwanted datasets (elastic#36753) During full sync the provider may have state from a previous dataset. So in the case that the user has changed dataset from users to devices or vice versa the provider may publish already existing state in the entity graph. This change adds conditional checks to ensure that unwanted dataset records are not published.
Proposed commit message
During full sync the provider may have state from a previous dataset. So in the case that the user has changed dataset from users to devices or vice versa the provider may publish already existing state in the entity graph. This change adds conditional checks to ensure that unwanted dataset records are not published.
Checklist
CHANGELOG.next.asciidoc
orCHANGELOG-developer.next.asciidoc
.Author's Checklist
How to test this PR locally
Related issues
Use cases
Screenshots
Logs