[Bug] Responder users fail to retrieve correct incidents under API

[gsreynolds]

Summary

This incident has been raised to identify and fix behaviours with calls to PagerDuty's API against two user types.

The implication of this bug means that responder users initially fetch the wrong incident dataset filled with duplicates, which are then removed on UI refresh from polling log_entries, furthermore showing another incorrect number of incidents for given query.

Current Behaviour

Global Admin

• GIVEN a Global Admin base-role user
• WHEN querying incidents that have multiple states
• THEN the correct number of incidents is returned by PD API
• Console debug - note unique incident numbers

Responder

• GIVEN a Responder base-role user
• WHEN querying incidents that have multiple states
• THEN the incorrect number of incidents is returned by PD API
• Console debug - note duplicate incident numbers

Expected Behaviour (Responder)

• GIVEN a Responder base-role user
• WHEN querying incidents that have multiple states
• THEN the correct number of incidents is returned by PD API

Suggested Workaround

TESTED: Default to older pd.all("/incidents") method to fetch incidents using a linear pagination method

[gsreynolds]

Working with @martindstone on debugging this issue - it looks like PD Live's call to PD API returns duplicates for responder users.

However, when replicating this using native REST calls with Postman, we are seeing no duplicates in the responses.

[gsreynolds]

On further investigation, this looks to be an environmental issue with PagerDuty itself and not PD Live. We have escalated this with PagerDuty engineering and will await further updates; unfortunately there is no workaround apart from granting users Global Admin base roles which is less than ideal.

[gsreynolds]

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