Geo containment alert sparsity handling: preserve active status for non-updated alerts

[kindsun]

Carries through active status for geo containment alerts that don't receive updates. To test, likely requires the faketracks script with the feature omitting capabilities added in this PR.

To test:

1. Set up containment alert w/ faketracks data using the random feature omission setting set to true
2. Observe that features that enter shapes but don't receive updates remain active in the alerting dashboard

Note: I would recommend using a boundary dataset with greater shape density than the one shown, otherwise you might find yourself waiting a while before a non-updated feature falls within a shape

[elasticmachine]

Pinging @elastic/kibana-gis (Team:Geo)

[thomasneirynck]

thx for the additions and offline explanations.

For the test coverage, I would actually test that the appropriate calls to scheduleActions are being made for a given alertInstance.

You could do that by creating a new alertInstanceFactory in each test. Something like:

const alerts = []
const alertInstanceFactory = (instance: string) => (
   return { 
   scheduleActions: (alert) => {
       alerts.push({instance, alert});
   };
 });

const newmap = getActiveEntriesAndGenerateAlerts(..., alertInstanceFactory,...);
expect(alerts).toEqual(...);

^. something like that, details tbd ;)

The reason for this is that this method does two things:

• create the new "previous state"
• generate the alerts

We're testing the first, but not the latter.

Otherwise, good to go, imho

[kindsun]

@thomasneirynck To follow up on a few items discussed offline:

• Agreed we should look consider a Map object that tracks more than a single shape entity location in the next PR. For the purposes of this PR, I've kept it the same focused solely on data sparsity using roughly the same algorithm employed for both geo threshold and containment.
• I confirmed that state is not preserved if an alert is disabled and later re-enabled
• I confirmed it's not possible to have a later date in the prevLocationMap. Both the prevLocationMap and the currLocationMap are sorted by entityName and dateInShape. The most recent dated entity of these is selected. The only difference between a prevLocationMap and a currLocationMap is the interval applied to their source query. Aside from this, they are both sorted by date with the most recent one grabbed for each entity. At best they might have identical entries.
• I've added tests ensuring scheduleAction calls are made using the correct entities pretty similarly to how you've laid out above.

Thanks for the feedback!

[kindsun]

@elasticmachine merge upstream

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 6fa86fc

Metrics [docs]

Distributable file count

id	before	after	diff
default	46991	47751	+760

History

• 💔 Build #93323 failed 8809de6
• 💔 Build #92968 failed 617d71c

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream