Skip to content
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

Pagerduty plugin cannot handle an escalation policy entry that contains a user instead of a schedule #1498

Closed
ghost opened this issue Jul 29, 2021 · 1 comment · Fixed by #1499

Comments

@ghost
Copy link

ghost commented Jul 29, 2021

Describe the bug
If a pagerduty escalation policy entry does not contain a schedule, Dispatch fails to find the appropriate contact.

To Reproduce
Steps to reproduce the behavior:
Create a Pagerduty escalation policy similar to the following
Screen Shot 2021-07-28 at 9 22 02 PM
Attempt to report an incident. The incident will not be created. Check the logs and you will see:

ERROR:No users could be found for this pagerduty escalation policy (*snip1*). Is there a schedule associated?:/usr/local/lib/python3.8/site-packages/dispatch/incident/views.py:create_incident:112         
Traceback (most recent call last):                                                                    
  File "/usr/local/lib/python3.8/site-packages/dispatch/incident/views.py", line 110, in create_incident                                                                                                    
    incident = create(db_session=db_session, **incident_in.dict())
  File "/usr/local/lib/python3.8/site-packages/dispatch/incident/service.py", line 228, in create
    assign_incident_role(
  File "/usr/local/lib/python3.8/site-packages/dispatch/incident/service.py", line 44, in assign_incident_role
    assignee_email = oncall_plugin.instance.get(service_id=service.external_id)
  File "/usr/local/lib/python3.8/site-packages/dispatch/decorators.py", line 106, in wrapper
    result = func(*args, **kwargs)
  File "/usr/local/lib/python3.8/site-packages/dispatch/decorators.py", line 122, in wrapper
    return func(*args, **kwargs)
  File "/usr/local/lib/python3.8/site-packages/dispatch/plugins/dispatch_pagerduty/plugin.py", line 33, in get
    return get_oncall(client=client, service_id=service_id)
  File "/usr/local/lib/python3.8/site-packages/dispatch/plugins/dispatch_pagerduty/service.py", line 35, in get_oncall
    return get_oncall_email(client, service)
  File "/usr/local/lib/python3.8/site-packages/dispatch/plugins/dispatch_pagerduty/service.py", line 24, in get_oncall_email
    raise Exception(
Exception: No users could be found for this pagerduty escalation policy (*snip1*). Is there a schedule associated?
INFO:     10.84.80.225:39996 - "POST /api/v1/default/incidents HTTP/1.1" 400 Bad Request

Expected behavior
get_oncall_email() should be aware of the possibility of an escalation policy entry that contains a user instead of a schedule. The exception message implies that a schedule is the only valid input in this spot, but that's not true.

Additional context
Running dispatch version from PR #1493
@ymatsiuk is under the red box in the screenshot

@ymatsiuk
Copy link
Contributor

In current plugin implementation we only filter on schedules, expecting that the first element of the escalation policy is schedule.

This is what PD's /escalation_policies API endpoint returns:

    "escalation_rules": [
      {
        ...
        "targets": [
          {
            "type": "user_reference",
            "summary": "Yurii Matsiuk",
            ...          }
        ]
      },
      {
        ...
        "targets": [
          {
            "type": "schedule_reference",
            "summary": "SRE Schedule Primary",
            ...
          }
        ]

As a quick workaround we can introduce conditional here to check for escalation_policy["escalation_rules"][0]["targets"][0]["type"] and if user_reference than replace this with user_ids[]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant