who's on call will return a block rather than individual mesages #79
Conversation
| @@ -570,9 +570,13 @@ module.exports = (robot) -> | |||
|
|
|||
| scheduleName = msg.match[1] | |||
|
|
|||
| messages = ["/code"] | |||
There was a problem hiding this comment.
Is this specific to an adapter? Not sure what it does.
There was a problem hiding this comment.
Ah, yeah. That is specific to HipChat. There should be some conditional statement there that adjusts depending on the adapter for this to work with Slack, etc. Is there a list somewhere of the supported adapters so that I could implement that?
There was a problem hiding this comment.
That's a good question. I've seen this happen with quite a few packages needing to implement an adapter-specific feature, but I don't have a ready example of someone who has done it well. The robot.adapterName property should be populated for most recent versions of Hubot.
There was a problem hiding this comment.
So, I found a list here https://hubot.github.com/docs/adapters/ and I don't think there's going to be any good way to support code-block formatting for all 30+ of those. I mean, it could be done, but the code would be convoluted and unreadable.
What could be done instead is to scrap the code-blocking, and just return the list joined with a newline.
There was a problem hiding this comment.
Yeah, I'd say scrap it. Ideally, Hubot would have a DSL of output formats that could be sent along with a message, and the adapters would handle those properly. Until then, the best approach is to send it along raw.
|
👍 |
who's on call will return a block rather than individual mesages
|
Released in |
The "who's on call" functionality intermittently works when the return payload is particularly large - sometimes returning only partial results, sometimes working perfectly, and sometimes returning nothing at all.
This PR address the issue of who's on call sending each returned item as an individual message by waiting for all results to be received and then concatenating them together. As an aside, it seems to fix the intermittent nature of the functionality due to hanging async requests, as described in #43.