Repository navigation
Bot doesn't handle being removed from the last Organization on Slack side #152
Description
Get the following error after I've removed the App from all Organizations when hitting the api/status end point. Not sure how or where this is getting called?
Side note: I tried cloning the repo and couldn't get the specs to run. (Failed on Bundler.require in the spec_helper.rb)
12:32:33 web.1 | E, [2022-10-28T12:32:33.241358 #55405] ERROR -- : Slack::Web::Api::Errors::AccountInactive: account_inactive
12:32:33 web.1 | ~/.gem/ruby/3.1.2/gems/slack-ruby-client-2.0.0/lib/slack/web/faraday/response/raise_error.rb:19:in `on_complete'
12:32:33 web.1 | ~/.gem/ruby/3.1.2/gems/faraday-2.6.0/lib/faraday/middleware.rb:18:in `block in call'
12:32:33 web.1 | ~/.gem/ruby/3.1.2/gems/faraday-2.6.0/lib/faraday/response.rb:42:in `on_complete'
12:32:33 web.1 | ~/.gem/ruby/3.1.2/gems/faraday-2.6.0/lib/faraday/middleware.rb:17:in `call'
12:32:33 web.1 | ~/.gem/ruby/3.1.2/gems/faraday-2.6.0/lib/faraday/request/url_encoded.rb:25:in `call'
12:32:33 web.1 | ~/.gem/ruby/3.1.2/gems/faraday-multipart-1.0.4/lib/faraday/multipart/middleware.rb:28:in `call'```
Activity
dblock commentedon Nov 1, 2022
The status endpoint is here. This error comes from calling
Team.ping. The stack should contain that at the very least.dblock commentedon Feb 18, 2023
@crazyoptimist if you want a challenging workitem after you release this is the one, I see it a lot in production where admins disable access to a bot in their settings, bot doesn't go offline properly and can't be restarted if reinstalled without bouncing the entire app
The api/status doesn't handle AccountInactive error appropriately either.
[-]After removing the App from the last Organization on Slack side.. The api/status doesn't handle AccountInactive error appropriately[/-][+]Bot doesn't handle being removed from the last Organization on Slack side[/+]dblock commentedon Oct 25, 2026
Opened #185 for the status-check failure: ping active installations only, deactivate
account_inactive/invalid_auththrough service callbacks, and return an explicit failed ping while preserving HTTP 200 and accurate active counts. Other failures still propagate. Existing OAuth reactivation regressions pass on both adapters.The RTM socket teardown/restart concern is separate and remains unresolved here: RTM was extracted to slack-ruby-bot-server-rtm, whose deactivation callback clears the server reference but does not itself stop the connection. Leaving this issue open rather than claiming the full lifecycle problem is fixed.
Posted by Copilot (AI), on behalf of @dblock.