test(slack): cover the task rebound during Socket Mode teardown - #1
Open
topseon23 wants to merge 1 commit into
Conversation
Guards the drain added in NousResearch#83693. Without it the rebound task is left as `Task pending ... connect() running` and keeps retrying against the closed shared session; with it teardown cancels the task and the retries stop. The production symptom is unbounded growth rather than one stray retry, so the test asserts that the closed-session retry counter stops moving, not just that the task was cancelled. `AsyncSocketModeHandler` defaults to `ping_interval=10` and `connect()`'s except branch sleeps exactly that between retries, so a single wedged loop is roughly 6 log lines per minute until the process restarts. The fake client rebinds `current_session_monitor` while `close()` is awaiting, which is what `connect()` does on success, so the task appears after the adapter's pre-close snapshot was taken. Refs NousResearch#46990.
altjs4510
pushed a commit
to altjs4510/hermes-agent
that referenced
this pull request
Aug 24, 2026
Upstream PR NousResearch#83693 fixes the same bug by re-reading the client task attributes after close_async(). Once it merges, drop this local sweep and take theirs — the fork diff on this file is already wide and the only behavioural difference (reachability-independent vs attribute re-read) is not worth carrying alone. Raised on the PR instead. Our rebind-window regression test is offered upstream as RelaxJonh#1. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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
1 participant
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.
Adds the regression test I offered in NousResearch#83693 (comment). Test only — no production code touched.
Why
The drain in NousResearch#83693 has no test, and this failure is easy to pin. The fake client here rebinds
current_session_monitorwhileclose()is awaiting, which is whatconnect()does on success, so the task appears after the adapter's pre-close snapshot was taken — the exact window the drain exists to cover.What it asserts
The production symptom is unbounded growth, not one stray retry, so the meaningful assertion is that the closed-session retry counter stops moving:
AsyncSocketModeHandlerdefaults toping_interval=10andconnect()'sexceptbranch sleeps exactly that between retries, so one wedged loop is ~6 log lines/min until the process restarts. We saw 6/min and 12/min (one and two orphans) in two separate windows, matching the count of precedingSocket Mode unhealthy (...); reconnectingevents.Verification
Against this branch:
4 passedTask pending ... connect() running— i.e. it does guard the fix rather than passing either wayFeel free to squash it into your branch instead of merging the PR if that is easier.