fix(cron): fall back to standalone delivery when live adapter fails silently - #47484
Closed
manus-use wants to merge 1 commit into
Closed
fix(cron): fall back to standalone delivery when live adapter fails silently#47484manus-use wants to merge 1 commit into
manus-use wants to merge 1 commit into
Conversation
… None or raises When the gateway has an active user session, the live adapter send() can return None or silently fail while the scheduler logs 'delivered'. This causes cron job output to be permanently lost without any error. Changes: - Treat send_result=None as a delivery failure, triggering standalone fallback - Catch all exceptions from future.result() (not just TimeoutError) and fall back to standalone instead of propagating - Log specific warnings for each failure mode (timeout, exception, None) - Initialize send_result before try block to avoid UnboundLocalError The standalone path uses a fresh event loop in a dedicated thread, which is immune to the active-session contention that affects the live adapter path. Fixes NousResearch#47056
alt-glitch
added
type/bug
Collaborator
Collaborator
|
Thanks for this. The silent-failure-on-live-adapter case (#47056) is now fixed on main in #50018 (02a3288) via an explicit delivery-confirmation check. Note the consolidated fix resolves the tension with #38922: an in-flight confirmation timeout is treated as delivered (re-sending would duplicate), while an unconfirmed/None result falls through to standalone. Closing as superseded — thanks for surfacing it. |
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
3 participants
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.
What
Fix cron job output being silently dropped when the gateway has an active user session.
Why
When a cron job completes while the user has an active conversation, the live adapter
send()can returnNoneor fail in a way that the scheduler still logs as "delivered". The message is permanently lost without any error or retry.Root cause: the condition
if send_result and not getattr(send_result, "success", True)evaluates toFalsewhensend_resultisNone(falsy), causingadapter_okto remainTrue. The scheduler reports successful delivery when no message was actually sent.How
send_result = Nonebefore the try blockfuture.result()(not just TimeoutError) — fall back to standalone.result(), explicitly checksend_result is None→ fall backif adapter_okso they only run when no prior failure occurredThe standalone fallback path runs in a fresh event loop on a dedicated thread, which is immune to the active-session contention that can cause the live adapter to silently fail.
Testing
The fix is defensive — the standalone path is already proven reliable (it's the non-live-adapter fallback that works for E2EE-exempt platforms). The change ensures it activates when the live adapter misbehaves.
Fixes #47056