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

Issue maybe? LOTs of queries to slack.com #105

Open
brad-colbert opened this issue Nov 16, 2020 · 7 comments
Open

Issue maybe? LOTs of queries to slack.com #105

brad-colbert opened this issue Nov 16, 2020 · 7 comments
Labels

Comments

@brad-colbert
Copy link

I'm not sure if this is an issue or something with how I configured the plugin or a bug but Octoslack is reaching out to Slack.com quite often. My Octopi is THE major DNS hit on my network. Over 700 times in 10 minutes according to PiHole.

@tedder
Copy link
Contributor

tedder commented Nov 17, 2020

You know what? When I first read this I didn't believe you, I thought it was the Slack apps that were doing it, but I just looked at my network traffic- and you're right.

Def gonna have to look into this. I'm sure it's on the "check for /octoprint commands" side, not the "post a status" side.

@tedder
Copy link
Contributor

tedder commented Nov 17, 2020

You might want to tail your octoprint log, @brad-colbert, and see if it is full of 429 errors.

@fraschetti
Copy link
Owner

fraschetti commented Nov 20, 2020

Hi @tedder and @brad-colbert

What you're seeing is the result of Slack removing support for the RTM (real-time messaging) API which relies on a persistent WebSocket. This unfortunately only leaves us with relying on polling their HTTP APIs to query for Slack API commands.
Out in the real world Slack API commands would call an endpoint to trigger our logic but that would require every OctoPrint/Octoslack instance to be exposed to the public internet and that's insane.
Instead I took the route of polling the Slack API ever 1.2 seconds as that keeps us beneath the Slack endpoint rate limits and also still allows the plugin to respond relatively quickly to any commands issues from Slack.
That said, I'm not a huge fan of hammering Slack unnecessarily so I built in a config option to increase this 1.2 seconds to a value of your choice.

If you can locate your OctoPrint config.yaml and the Octoslack config section, you can add the entry below to change the refresh interval (how often we'll query Slack for new messages) from the default 1.2 seconds to 30 seconds.

slack_apitoken_config:
    messages_query_delay: "30"

1.2 seconds is about as hard as I could push querying that API and it was "OK" as long as it was transparent - it doesn't impact you or your network. Give this a try but also feel free to share your thoughts here.

@brad-colbert
Copy link
Author

Hi @fraschetti,

Makes total sense. I suspected that was the case but wanted to make sure I hadn't broken anything in updating.

I appreciate the configuration option. Thanks again!

@fraschetti
Copy link
Owner

FYI the default polling interval has been changed from 1.2s to 5s. I'm leaving this issue open until I surface this config via the UI and/or find a solution that doesn't require this polling.

For context, I also run Pi-hole but my 3D printer has been offline for a while (had to be rebuilt) so these lookups hadn't hit my radar. I don't rely on the Slack channel commands all that often so I changed my poll interval to 30 (seconds) to remove the noise.

@fraschetti
Copy link
Owner

Update: Slack has introduced 'Socket Mode' which I still need to look into but appears to be a replacement for RTM. I'll check this out as time permits to see if can replace this polling logic.
https://api.slack.com/apis/connections/socket

@jasonappah
Copy link

Would you be willing to accept a PR implementing Socket Mode? Not making any guarantees as to if/when I'd get around to making the PR, but I'd love to give it a crack.

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

No branches or pull requests

4 participants