greetingslack
greetingslack copied to clipboard
orliesaurus
Clarify that this app runs on a worker and why
Hi there! Thanks so much for this tool!
I've just realized that worker apps don't sleep, and so this app has unfortunately broughts all my free apps to a grinding halt for the month. (Wome of which are pretty critical, although shame on me for getting into that situations)
Getting things sorted on heroku is a little kafkaesque, as it's not as clear as throwing money at the problem :)
Anyhow, to help someone else from getting hit like this, I was wondering if there were any way to move this to using a web process, so that normal heroku sleeps come into play :)
Thoughts?
Hey, @patcon
I don't understand the problem because (luckily) I don't use Heroku. I added Heroku because it makes it so much simpler for people to use this slackbot.
Wouldn't the best advice just create a new Heroku account that has no other apps running alongside it? Alternatively, moving this to a web-process would force the bot to sleep - so that would break it?
You're right, that would totally be a partial work-around for some of my very specific woes :)
but I feel there's perhaps another rationale for having this app work a bit more intuitively within heroku users' assumptions: if someone isn't paying, then they should expect sleep happen, right? If they don't want it to sleep, then they should knowingly start paying, instead of having this app take them into a countdown of "heroku dyno debt" through a bit of a work-around. Even with a separate account, the approach here invites users to run a 24 hour worker dyno (that can't intelligently sleep) without paying, and so 3 weeks into using the bot (at perhaps about the time that people start trusting and depending on it), heroku shuts down the app due to overage, and the bot (perhaps unknowingly) goes down, and breaks their onboarding. This seems like a bad thing to set people up for, no? :)
At least with a web dyno, people can think on using something like https://github.com/hubot-scripts/hubot-heroku-keepalive, and keep itself awake during certain hours (when people most often use slack).
tl;dr - current setup just defers dealing with the dyno restrictions in an overly clever way that sets people up for later difficulty :)
@patcon Ok - I never had a complaint from any of the people that run the bot. I have a friend who runs a community for podcasters whose bot has been running for 3 months without shutting down. I understand the issue better now at least. Maybe if I fork the project and make it behave as a web-dyno version then this would overcome the issue you mentioned. The other solution is to pay Heroku fees... #foodforthought Not sure what's the path to take here...
Totally. I'm willing to work on a solution too, so not all on you. i expect to be back into onboarding process mode at some point, and would be happy to loop back to convo then!
(fwiw, due to how heroku tallies dyno hours in aggregate, someone with a bunch of heroku apps might see the "debt" of this app masked by surplus hours on other quiet apps. at least that's my analysis of the situation :)
I think this is a result of choosing to use the Slack RTM api instead of the Events and Web API.
I found this repo from a Medium article while looking for this type of functionality for a hobby-related Slack. Really cool stuff and a great idea!
To get around the worker always running issue, I ended up converting to the web api and running as a Cloud Function on GCP. That way, you subscribe to certain events in slack and the function only executes when the event is triggered - no servers/workers. Has worked really well so far!
Happy to discuss implementation with you guys if desired. Thanks for the inspiration!
@gundmc great to hear: this bot was written many years ago, there was no event api back then, it would be cool to see others update the code or create their own now that it is possible and just like you did use serverless platforms with hooks
I'd love to check out that code @gundmc! Are you planning to release in another project? :)