Hello, really loving Glitch so far, thanks for the awesome platform!
Iâm currently using it to host a Botkit Slack bot, and for the most part, itâs been working great, howeverâŚ
Iâve noticed that if the bot doesnât get queried after a certain amount of time, it goes âidleâ(Itâs uptime counter resets), and when it gets queried in this âidle stateâ(may not be using the right lingo here), it duplicates the output of the query. After the initial query when it was idle, all following query output is normal(non-duplicated).
Iâm currently using it to post PagerDuty information into Slack channels, so for example, if you â@pagerduty whoâs on call?â while the bot is âidleâ, youâll getâŚ
*- IT Escalation level 1 - John Smith | BACKUP ON CALL
*- IT Escalation level 1 - John Smith | BACKUP ON CALL
Then if you immediately ask it again, youâll simply getâŚ
*- IT Escalation level 1 - John Smith | BACKUP ON CALL
This seems to only happen when the bot gets a query while itâs in the âidle stateâ, then itâs fine for every query after thatâŚ
Searched this forum, Google, Botkit, and Slack for any clue as to whatâs going on, and so far have been empty handed⌠itâs a real head scratcher for me. Maybe someone on here can throw me a bone
Difficult to know whatâs causing this. Although for background in case you didnât know, the idle state is expected - Glitch apps sleep after 5 mins of inactivity (https://glitch.com/faq#restrictions). If you can share your project then we can take a closer look at this.
Yeah, I assumed the idle state was expected behavior Only thing thatâs odd, is how the bot seems to duplicate output immediately upon resuming from the idle state, then behaves normally after thatâŚ
Hereâs a Codeshare of the only Skill/code Iâve setup in the Botkit bot. Everything else is standard âout of the boxâ Botkit code. https://codeshare.io/ayDyAq
I havenât used any of the botkit code with Slack, but I did have a similar issue with one of my Slack integrations.
If youâre subscribing to the Slack Events API thereâs an automatic retry of failed messages. If your app is too slow coming out of the idle state and replying, Slack will immediately retry. Because of the way that Glitch holds a request active while starting your app, itâs entirely possible youâll get duplicate messages. Iâd expect similar retry behavior on the rest of the Slack payloads (if youâre not using Events API).
The way Iâve handled that in a few of my Slack projects is to reply with 200 OK as soon as possible and then deal with the message as appropriate. That was sufficient to get my apps up and responding in time to avoid the triggering the retry, resulting in duplicated responses.
Awesome, thanks for the input, both those suggestions definitely make sense
Things are busy right now, so itâll be âweeksâ before I find time to sit down and hammer out some code to try and fix this, but now I have a direction to go. Iâll post my solution/update once I make headway.
Itâs been a while since I last played with this, so my memory is a bit foggy. This route handler exhibits the ârespond to Slack right awayâ behavior I mentioned: https://glitch.com/edit/#!/shadow-rooster?path=slack.js:132:0 (your cursor will be at the right line after following the link, but youâll need to scroll down to see it)
// https://api.slack.com/events-api
app.post(options.eventsRoute, function (request, response) {
if (request.body.challenge) {
response.send(request.body.challenge) // reply to Slack attempting to configure the events API
} else if (request.body.token === process.env.SLACK_TOKEN) {
response.send('ok') // let Slack know we'll handle this
handleEvent(request.body.event) // do whatever we need to do based on the message
} else {
response.status(400).send('nope') // if the request doesn't have
}
})
The handler below the âearly returnâ version canât return early, because we need to have the response to Slack actually have the results when dealing with interactive button messages. https://glitch.com/edit/#!/shadow-rooster?path=slack.js:144:0
Hope that helps!
(No guarantees about the app functioning, though⌠itâs been a year since I last used it)