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

Doesn't return all on-call schedules #43

Open
mcg opened this issue Jun 8, 2015 · 9 comments
Open

Doesn't return all on-call schedules #43

mcg opened this issue Jun 8, 2015 · 9 comments
Labels

Comments

@mcg
Copy link

mcg commented Jun 8, 2015

We have a large number of on-call schedules. "Who is on call" only lists some subset. My guess is that we are only getting the first "page" of results from the PD API and pagination is not being used. See "This action is paginated. See the pagination documentation for details." here,
https://developer.pagerduty.com/documentation/rest/schedules/list

@mcg
Copy link
Author

mcg commented Jun 8, 2015

Also forgot to mention that the returned subset of results are different each time "who is on call" is used.

@technicalpickles
Copy link
Contributor

The default (in most places) is 100 results. This script currently uses msg.send for each schedule found which could flood a channel/room/whatever, so that might need to be revisited as part of this.

@danoc
Copy link

danoc commented Sep 6, 2015

@technicalpickles – Any chance this will be worked on? Or tips on how to fix it? Spent about two hours trying to fix this with no luck.

@danoc
Copy link

danoc commented Sep 6, 2015

@technicalpickles – I eventually fixed it on my end on a heavily modified fork of this repo: https://github.com/optimizely/hubot-pager-me/blob/devel/src/scripts/pagerduty.coffee

I also eliminated most of the features since we only want the "who is on call" functionality.

The code isn't very elegant but it works (and I already spent way too long working on it 😄)!

@technicalpickles
Copy link
Contributor

@danoc I took a look at your fork, and I'm not seeing anything obvious that fixes the issue you reported. I would have guessed that we needed to deal with pagination or something, but I don't see code for that. Interestingly, I've been working on some refactorings that also use the async module.

@danoc
Copy link

danoc commented Oct 15, 2015

@technicalpickles I guess my issue may be a little different. We only have around 20 schedules, but flooding Slack with that many msg.send's would cause Hubot to crash before printing all of the schedules.

My solution uses async.map to loop through the schedules, get an array of who is on call messages, and then join that array and only print it once: https://github.com/optimizely/hubot-pager-me/blob/798edc845e24f9e043a7f11c23ab6fb32faa981d/src/scripts/pagerduty.coffee#L35-L37

See async.map example: https://github.com/caolan/async#quick-examples

@technicalpickles
Copy link
Contributor

My solution uses async.map to loop through the schedules, get an array of who is on call messages, and then join that array and only print it once: https://github.com/optimizely/hubot-pager-me/blob/798edc845e24f9e043a7f11c23ab6fb32faa981d/src/scripts/pagerduty.coffee#L35-L37

That's exactly what #50 does too 😁

@danoc
Copy link

danoc commented Oct 15, 2015

@technicalpickles Heh, awesome. Thanks! I guess my issue is different then.

@kaesackett
Copy link

We were also having this same issue, @danoc. I eventually ended up requesting the who's on call list one person at a time, appending each result to an array as it came back, and then sending the array as the message. I put in the PR to fix this at its source and made sure to mention this issue.

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

No branches or pull requests

4 participants