[Bug] Inconsistent incidents when filtered by escalation policy compared to teams

[gsreynolds]

Summary

There have been reports of inconsistent filtering of incidents by escalation policy compared to teams within PD Live.
e.g. filtering by EP "Team A" (associated with Team A) shows different results than filtering from Team "Team A" itself.

This feature was introduced under #263 but may also be related to ongoing bug giranm#175.

[gsreynolds]

For some additional context, the PD REST API for GET /incidents only allows you to do server side querying based on:

• Statuses
• Urgencies
• Service IDs
• Team IDs
• User IDs

Prior to the introduction of the alerts data in view (#137), we used to fetch the entire incident dataset (for the given query up to 10,000 records), then apply the truncation and post-filtering (priorities only supported at that time).

In order to support alerts data in the view (consuming a separate API call PER incident), we implemented the hard max incidents limit - initially 200 (#132), then set to a configurable limit up to 1000 (#143) - in order to ensure that users were within the API rate limits of 2000 API calls per minute.

On reflection of this issue, it would appear that this underlying behaviour has always existed since the inclusion of the alerts data enhancement, but only became visible when the introduction of EP was introduced (#263).
e.g. using EP as a substitution for team filtering.

Given this - there are two possible solutions here:

• Reintroduce fetch of 10,000 incidents, apply local filters, then truncate dataset on maxIncidentsLimit, to ensure we're not missing any incidents outside of API query.
• Raise core product enhancement with PagerDuty Engineering to support priority_ids[] and escalation_policy_ids[] in the query parameters

[gsreynolds]

Not planned; project deprecated in favour of [Operations Console].(https://support.pagerduty.com/main/docs/operations-console)