Description

In a specific case of magic resolution in live stream, volume of reports can sometimes be to large to be correctly fetch by elastic.
This situation leads to read failure and stream consumption stop.

Hints

Let explain a bit why this "magic" is needed.
Assuming you want to share containers inside a live stream, you will create for example a live stream with filters configuration like this : Entity type = Report and Label = Sharing.
With this kind of configuration you expect to also share everything related the the container. But you also need to detect a change inside a element of the report to be able to share it into the stream to update the remove platform. However this element is not container and have no label. To handle this the platform needs to auto detect this behavior to let this element be pushed in the stream. For this we need to list reports connected to this element, resolve them and try to use the configured filters on it. This issue aims to improve this algorithm to fetch less data.

Todo

Change the approach to forge the correct filters to directly count the potential result
If count > 0 publication must be done