fix: use longer bridge timeout for send actions by omarshahine · Pull Request #139 · openclaw/imsg

omarshahine · 2026-06-07T01:22:34Z

Summary

use a 150s default bridge response timeout for send-style actions
cover message, multipart, attachment, poll, and tapback/reaction bridge sends
keep the existing 10s default for non-send bridge actions, including notify-anyways
preserve explicit per-call timeout overrides such as short status probes

This backs the OpenClaw iMessage send timeout in openclaw/openclaw#91041 at the actual imsg bridge layer.

Verification

swift format lint Sources/IMsgCore/IMsgBridgeClient.swift Sources/IMsgCore/IMsgBridgeProtocol.swift Tests/IMsgCoreTests/IMsgBridgeProtocolTests.swift
DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer swift test --filter IMsgBridgeProtocolTests
DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer swift test --filter RPCBridgeMessageHandlersTests --filter RPCServerBridgeTests --filter BridgeRichCommandTests
DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer make test (325 tests in 2 suites passed)

Notes

.sendReaction is included because tapbacks build an IMMessage and dispatch through [chat sendMessage:], so they can hit the same private-send wait class.
.notifyAnyways intentionally remains on the 10s default because it uses a separate message-item mutation path rather than dispatching a send.

clawsweeper · 2026-06-07T01:23:42Z

Codex review: needs real behavior proof before merge. Reviewed June 6, 2026, 10:01 PM ET / 02:01 UTC.

Summary
The PR changes bridge invokes to use an action-specific default timeout, raising send-style v2 bridge actions to 150s while preserving explicit overrides and the 10s default for non-send actions, with protocol tests.

Reproducibility: no. high-confidence live reproduction is included. Source inspection confirms current main gives send-style bridge actions the same 10s default as every other action, but the PR does not include live macOS output showing a send completing after more than 10s.

Review metrics: 2 noteworthy metrics.

Send wait default: 10s -> 150s for 5 BridgeAction cases. This is the user-visible availability tradeoff that unit tests alone do not settle.
Changed surface: 2 source files, 1 test file. The diff is narrow and centered on bridge timeout selection plus regression coverage.

Merge readiness
Overall: 🧂 unranked krab
Proof: 🧂 unranked krab
Patch quality: 🐚 platinum hermit
Result: blocked until real behavior proof is added.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

[P1] Add redacted live macOS bridge-send proof showing the after-fix behavior for a slow send path.
State whether maintainers should intentionally accept the 150s maximum wait for stuck send actions.

Proof guidance:

[P1] Needs real behavior proof before merge: The PR provides lint and test results only; before merge, add redacted live bridge-send output, terminal screenshot, logs, recording, or linked artifact from a real macOS Messages setup, redact private data, then update the PR body to trigger re-review or ask a maintainer to comment @clawsweeper re-review.

Risk before merge

[P1] A covered send that never produces a bridge response will now keep the CLI/RPC caller waiting up to 150s instead of 10s, so the longer failure wait should be an intentional maintainer tradeoff.
[P2] Verification is still test-only; reviewers do not yet have redacted live macOS Messages bridge-send evidence showing the longer timeout fixes the observed slow private-send path.

Maintainer options:

Require live bridge-send proof (recommended)
Ask for redacted macOS bridge-send output or logs that show a slow send completing under the 150s window before merging the availability tradeoff.
Accept the longer wait explicitly
Maintainers may choose to merge with test-only proof if they intentionally accept that stuck send actions can hold callers for up to 150s.
Pause until timeout policy is settled
If 150s is too high as a default, pause this PR and choose a narrower timeout policy or configurable strict path first.

Next step before merge

[P1] The remaining blocker is contributor-supplied live proof plus maintainer acceptance of the longer failure wait; there is no narrow code repair left for automation.

Security
Cleared: The diff only changes bridge timeout selection and protocol tests; it does not touch dependencies, CI, secrets, downloaded artifacts, or publishing paths.

Review details

Best possible solution:

Land the narrow action-specific timeout helper after redacted live macOS bridge-send proof shows slow sends complete within the longer window and maintainers accept the 150s failure wait.

Do we have a high-confidence way to reproduce the issue?

No high-confidence live reproduction is included. Source inspection confirms current main gives send-style bridge actions the same 10s default as every other action, but the PR does not include live macOS output showing a send completing after more than 10s.

Is this the best way to solve the issue?

Yes, the code path is narrow and covers message, multipart, attachment, poll, and tapback sends while preserving explicit overrides and non-send defaults. The remaining concern is proof and maintainer acceptance of the timeout tradeoff, not a mechanical code defect.

AGENTS.md: found and applied where relevant.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 041b40686a6d.

Label changes

Label justifications:

P2: This is a normal-priority bridge reliability fix with limited surface, not a security, data-loss, or core runtime emergency.
merge-risk: 🚨 availability: Merging changes the failure wait for covered send actions from 10s to 150s when the bridge never returns a response.
rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🐚 platinum hermit.
status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: The PR provides lint and test results only; before merge, add redacted live bridge-send output, terminal screenshot, logs, recording, or linked artifact from a real macOS Messages setup, redact private data, then update the PR body to trigger re-review or ask a maintainer to comment @clawsweeper re-review.

Evidence reviewed

What I checked:

Repository policy read: AGENTS.md was present and read fully; its Swift/testing and PR verification guidance was applied while reviewing the bridge timeout change. (AGENTS.md:1, 041b40686a6d)
No matching maintainer notes: The repository has skill files under .agents but no maintainer-notes directory or file matching this bridge timeout review.
Current main uses one 10s default: On current main, IMsgBridgeClient.invoke defaults timeout to IMsgBridgeProtocol.defaultResponseTimeout, and IMsgBridgeProtocol defines that default as 10.0 with no action-specific send timeout. (Sources/IMsgCore/IMsgBridgeClient.swift:41, 041b40686a6d)
PR maps all send-style bridge actions to 150s: The PR commit changes invoke's timeout parameter to optional, computes the effective timeout from defaultResponseTimeout(for:), and maps sendMessage, sendMultipart, sendAttachment, sendPoll, and sendReaction to defaultSendResponseTimeout = 150.0. (Sources/IMsgCore/IMsgBridgeProtocol.swift:28, 4c85d165c31f)
Regression tests cover the timeout split: The PR adds protocol tests asserting the 150s timeout for the five send-style actions and the 10s default for representative non-send actions including notifyAnyways. (Tests/IMsgCoreTests/IMsgBridgeProtocolTests.swift:86, 4c85d165c31f)
Tapback and notify-anyways paths match the PR's classification: Current main dispatches send-reaction through [chat sendMessage:], while notify-anyways uses markChatItemAsNotifyRecipient:, supporting the PR's long-timeout inclusion for tapbacks and exclusion for notify-anyways. (Sources/IMsgHelper/IMsgInjected.m:3304, 041b40686a6d)

Likely related people:

Omar Shahine: Introduced the BlueBubbles private-API bridge touching IMsgBridgeClient, IMsgBridgeProtocol, IMsgInjected.m, and BridgeMessagingCommands in c56c24d, so the timeout surface is in prior merged work by this contributor. (role: introduced bridge behavior; confidence: high; commits: c56c24d488ef; files: Sources/IMsgCore/IMsgBridgeClient.swift, Sources/IMsgCore/IMsgBridgeProtocol.swift, Sources/IMsgHelper/IMsgInjected.m)
Peter Steinberger: Exposed bridge message RPC methods in b71eb8c and authored the current v0.11.0 release commit that owns the main-branch bridge file lines inspected here; shortlog also shows the most touches across the affected bridge/RPC paths. (role: recent area contributor; confidence: high; commits: b71eb8c0f6f1, c3205e1361bf, 9db467fe5347; files: Sources/imsg/RPCServer+BridgeMessageHandlers.swift, Sources/imsg/RPCServer.swift, Sources/IMsgCore/IMsgBridgeClient.swift)

What the crustacean ranks mean

🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works

ClawSweeper keeps one durable marker-backed review comment per issue or PR.
Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
Maintainers can also comment @clawsweeper review to request a fresh review only.
Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

omarshahine · 2026-06-07T01:56:01Z

@clawsweeper re-review

Addressed the timeout coverage finding:

Added .sendReaction to the 150s send-timeout mapping.
Added protocol test coverage for .sendReaction using the long timeout.
Added explicit protocol test coverage that .notifyAnyways remains on the 10s default because it is a message-item mutation path, not a sendMessage: dispatch path.

Fresh verification after the patch:

swift format lint Sources/IMsgCore/IMsgBridgeProtocol.swift Tests/IMsgCoreTests/IMsgBridgeProtocolTests.swift
DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer swift test --filter IMsgBridgeProtocolTests (7 tests passed)
DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer make test (325 tests in 2 suites passed)

clawsweeper · 2026-06-07T01:56:03Z

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

Re-review progress:

State: Complete
Detail: The targeted re-review finished, the durable review comment was updated, and the synced verdict was routed.
Run: https://github.com/openclaw/clawsweeper/actions/runs/27079737684
Updated: 2026-06-07T02:02:08.232Z

…d timeout (#91041) Append imsg's own status message (SIP / library validation / macOS 26 AMFI gate) to iMessage private-API blocked-action errors so operators see the real blocker instead of a generic "run imsg launch". Add a dedicated 150s default timeout for iMessage send RPCs (explicit opts and probeTimeoutMs still win) so macOS 26 bridge stalls are not aborted mid-send. Staged mitigation: the longer wait fully activates once the companion bridge timeout (openclaw/imsg#139) ships; on current imsg the bridge still returns at its own 10s, so there is no regression. Diagnostics half is live-proven; the delayed-send timeout is covered by source + unit proof + maintainer waiver.

…d timeout (openclaw#91041) Append imsg's own status message (SIP / library validation / macOS 26 AMFI gate) to iMessage private-API blocked-action errors so operators see the real blocker instead of a generic "run imsg launch". Add a dedicated 150s default timeout for iMessage send RPCs (explicit opts and probeTimeoutMs still win) so macOS 26 bridge stalls are not aborted mid-send. Staged mitigation: the longer wait fully activates once the companion bridge timeout (openclaw/imsg#139) ships; on current imsg the bridge still returns at its own 10s, so there is no regression. Diagnostics half is live-proven; the delayed-send timeout is covered by source + unit proof + maintainer waiver.

steipete · 2026-06-10T08:13:45Z

Maintainer proof/update after rebasing and tightening this PR:

Rebased on current main after feat: expose message balloon bundle metadata #137/fix(bridge): defer dylib init off the constructor (macOS 26 dyld init-order) #138.
Preserved the public explicit-timeout IMsgBridgeClient.invoke(... timeout:) API by adding a no-timeout overload for action-specific defaults.
Extended the long 150s default to bridge sends plus create-chat initial-message sends, while keeping probe/mutation calls on the 10s default.
Threaded explicit timeouts through legacy IPC as well as v2 IPC.
Maintainer accepts the tradeoff: stuck send-style bridge requests can now wait up to 150s; short probe/mutation waits stay at 10s.

Verification:

make format
make lint (passes; existing 11 non-serious warnings only)
make test (330 tests passed)
autoreview --mode branch --base main (clean; no accepted/actionable findings)
GitHub Actions on c8296e6: linux-read-core passed, macos passed

Caveat: I could not add redacted live slow-send bridge proof because the available macOS hosts are SIP-enabled, so this merge is based on source-level verification, local tests, CI, and explicit maintainer acceptance of the longer send wait.

omarshahine mentioned this pull request Jun 7, 2026

fix(imessage): self-explaining private-API failures and dedicated send timeout openclaw/openclaw#91041

Merged

omarshahine force-pushed the fix/bridge-send-timeout branch from 08d2d9a to 4c85d16 Compare June 7, 2026 01:55

omarshahine and others added 5 commits June 10, 2026 08:56

fix: extend bridge send timeout

91742e4

docs(changelog): note bridge send timeout

1533ad1

fix: preserve bridge client timeout API

322669a

fix: extend bridge timeout to initial chat creation

5c15958

fix: apply bridge send timeout to legacy IPC

c8296e6

steipete force-pushed the fix/bridge-send-timeout branch from 4c85d16 to c8296e6 Compare June 10, 2026 08:11

steipete merged commit a35aec8 into openclaw:main Jun 10, 2026
2 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix: use longer bridge timeout for send actions#139

fix: use longer bridge timeout for send actions#139
steipete merged 5 commits into
openclaw:mainfrom
omarshahine:fix/bridge-send-timeout

omarshahine commented Jun 7, 2026 •

edited

Loading

Uh oh!

clawsweeper Bot commented Jun 7, 2026 •

edited

Loading

Uh oh!

omarshahine commented Jun 7, 2026

Uh oh!

clawsweeper Bot commented Jun 7, 2026 •

edited

Loading

Uh oh!

steipete commented Jun 10, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

omarshahine commented Jun 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Verification

Notes

Uh oh!

clawsweeper Bot commented Jun 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

omarshahine commented Jun 7, 2026

Uh oh!

clawsweeper Bot commented Jun 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

steipete commented Jun 10, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

omarshahine commented Jun 7, 2026 •

edited

Loading

clawsweeper Bot commented Jun 7, 2026 •

edited

Loading

clawsweeper Bot commented Jun 7, 2026 •

edited

Loading