fix(gateway): release platform locks on Slack/Signal connect failure - #5519
Closed
binhnt92 wants to merge 1 commit into
Closed
fix(gateway): release platform locks on Slack/Signal connect failure#5519binhnt92 wants to merge 1 commit into
binhnt92 wants to merge 1 commit into
Conversation
When Slack's connect() acquires a scoped lock on the app token and then fails (bad token, Socket Mode error), the lock is never released. The next gateway start sees "Slack app token already in use" and refuses to connect until the process dies. Same issue in Signal: if the health check fails after acquiring the phone lock, the lock is held permanently. Discord got this fix in PR NousResearch#5302. Slack and Signal were missed. Add lock release to both exception/failure paths. Extract Signal's inline release logic into a reusable _release_phone_lock() helper. Also close the leaked httpx client on Signal health check failure.
3 tasks
Contributor
|
Thanks for the fix, @binhnt92 — the lock-release behavior you identified is a real correctness issue and the analysis is solid. This is an automated hermes-sweeper review. Unfortunately this change was already landed by a different contributor before this PR could be merged:
Current |
Collaborator
|
Likely duplicate of #12916 (merged) — same fix: release scoped locks on Slack/Signal connect failure. That PR already addressed this in gateway/platforms/slack.py and gateway/platforms/signal.py. |
Collaborator
|
Likely duplicate of #12916 (merged) |
1 similar comment
Collaborator
|
Likely duplicate of #12916 (merged) |
19 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When Slack's
connect()acquires a scoped lock on the app token and then fails (bad token, Socket Mode error, network issue), the lock is never released. The nexthermes gateway restartsees "Slack app token already in use" and refuses to connect — the gateway is stuck until the process dies.Same issue in Signal: if the health check fails after acquiring the phone lock, the lock is held permanently. The next start sees "Another local Hermes gateway is already using this Signal account" even with no other gateway running.
Changes Made
Slack (
gateway/platforms/slack.py):release_scoped_lock('slack-app-token', ...)in theexcept Exceptionblock ofconnect()Signal (
gateway/platforms/signal.py):disconnect()into reusable_release_phone_lock()helper_release_phone_lock()+client.aclose()on both health check failure paths (non-200 and exception)How to Test
4 tests: Slack except block releases lock, Signal health check releases lock on both paths, Signal helper method exists, Signal closes httpx client on failure.
Checklist