fix: register BlueBubbles webhook route before server-info fetch#657
Open
BingqingLyu wants to merge 4 commits intomainfrom
Open
fix: register BlueBubbles webhook route before server-info fetch#657BingqingLyu wants to merge 4 commits intomainfrom
BingqingLyu wants to merge 4 commits intomainfrom
Conversation
…cation Slack sends url_verification challenges WITHOUT a signature (by design). The HTTPReceiver was rejecting these requests because it verifies signatures on ALL requests, but url_verification is never signed. This fix intercepts incoming HTTP requests BEFORE they reach the receiver's signature verification: 1. Read the request body first 2. Check if it's a url_verification request 3. If yes, respond directly with the challenge (no signature needed) 4. If no, replay the body to the receiver using a PassThrough stream This allows HTTP webhook mode to complete the Slack handshake and activate properly, fixing the regression in v2026.3.2. Closes openclaw#39432
Handle file lock errors gracefully when .openclaw directory is synced via cloud storage services (OneDrive, Dropbox, Google Drive, etc.). Retry up to 3 times with exponential backoff before failing. Fixes openclaw#39446
fix: add retry logic for file lock errors (EBUSY, EACCES, EPERM)
Previously, monitorBlueBubblesProvider called fetchBlueBubblesServerInfo (up to 5 s timeout) *before* registering the webhook HTTP route. This created a window on every startup and after every crash-loop restart where POST /bluebubbles-webhook returned 404: the plugin HTTP registry had no matching entry yet so the request fell all the way through the gateway's stage pipeline. Fix: move registerBlueBubblesWebhookTarget to the top of the function, before the async server-info fetch, so the route is reachable as soon as the provider (re)starts. Also fix an off-by-one in server-channels restart accounting: when the crash-loop hit MAX_RESTART_ATTEMPTS + 1 it was reporting reconnectAttempts = MAX + 1 instead of MAX, causing the snapshot to show one extra attempt than the configured cap. Fixes openclaw#45620
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
2 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.
Summary
monitorBlueBubblesProviderwas callingfetchBlueBubblesServerInfo(up to 5 s timeout) before registering the webhook HTTP route viaregisterBlueBubblesWebhookTarget. This created a gap on every startup and after every crash-loop restart where the plugin HTTP registry had no entry for/bluebubbles-webhook, so the request fell through all gateway stages and returned404 Not Found.Changes
extensions/bluebubbles/src/monitor.ts— MoveregisterBlueBubblesWebhookTargetto the top ofmonitorBlueBubblesProvider, before the asyncfetchBlueBubblesServerInfocall. The webhook route is now reachable immediately when the provider starts or restarts; server info is still fetched and cached for macOS version detection.src/gateway/server-channels.ts— Fix off-by-one in crash-loop restart accounting: when the loop hitMAX_RESTART_ATTEMPTS + 1it was settingreconnectAttempts = MAX + 1(e.g. 11) instead ofMAX(10). Now caps the reported value atMAX_RESTART_ATTEMPTS.Testing
extensions/bluebubbles/src/monitor.test.ts— 60 tests pass (no regressions in webhook parsing, auth, and routing)extensions/bluebubbles/src/monitor.webhook-route.test.ts— 1 test passesextensions/bluebubbles/src/monitor.webhook-auth.test.ts— 16 tests passsrc/gateway/server-channels.test.ts— all 4 tests pass (including the previously-failing "caps crash-loop restarts after max attempts")src/gateway/server.plugin-http-auth.test.ts— 21 tests passsrc/gateway/control-ui-routing.test.ts— 16 tests passFixes openclaw#45620