iOS/watch: add actionable watch approvals and quick replies by mbelinky · Pull Request #21996 · openclaw/openclaw

mbelinky · 2026-02-20T16:14:54Z

Summary

Describe the problem and fix in 2–5 bullets:

Problem:
Why it matters:
What changed:
What did NOT change (scope boundary):

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

Closes #
Related #

User-visible / Behavior Changes

List user-visible changes (including defaults/config).
If none, write None.

Security Impact (required)

New permissions/capabilities? (Yes/No)
Secrets/tokens handling changed? (Yes/No)
New/changed network calls? (Yes/No)
Command/tool execution surface changed? (Yes/No)
Data access scope changed? (Yes/No)
If any Yes, explain risk + mitigation:

Repro + Verification

Environment

OS:
Runtime/container:
Model/provider:
Integration/channel (if any):
Relevant config (redacted):

Steps

Expected

Actual

Evidence

Attach at least one:

Failing test/log before + passing after
Trace/log snippets
Screenshot/recording
Perf numbers (if relevant)

Human Verification (required)

What you personally verified (not just CI), and how:

Verified scenarios:
Edge cases checked:
What you did not verify:

Compatibility / Migration

Backward compatible? (Yes/No)
Config/env changes? (Yes/No)
Migration needed? (Yes/No)
If yes, exact upgrade steps:

Failure Recovery (if this breaks)

How to disable/revert this change quickly:
Files/config to restore:
Known bad symptoms reviewers should watch for:

Risks and Mitigations

List only real risks for this PR. Add/remove entries as needed. If none, write None.

Risk:
- Mitigation:

Greptile Summary

added actionable watch approvals and quick replies to iOS/watchOS apps

Major changes:

Extended OpenClawWatchNotifyParams with prompt metadata (promptId, sessionKey, kind, details, expiresAtMs, risk, actions)
Implemented bidirectional watch communication: iPhone receives replies from Apple Watch via WatchConnectivity delegates
Added queuing for watch replies when gateway is offline, with automatic flush on reconnect
Watch UI now renders action buttons with styles (destructive/cancel) and shows reply status
Haptic feedback varies by risk level (high=failure, medium=notification, low=click)

Issues found:

Retry logic has a deduplication bug that silently drops failed replies on retry

Confidence Score: 3/5

safe to merge after fixing the retry deduplication bug
the PR implements a solid bidirectional watch messaging feature with proper queuing, haptics, and UI updates, but contains one critical logical error in the retry mechanism where failed replies get silently dropped due to deduplication. the test coverage is present but doesn't catch this edge case. the rest of the implementation follows good patterns with proper locking, error handling, and state management
pay close attention to apps/ios/Sources/Model/NodeAppModel.swift:2324 for the retry deduplication fix

_{Last reviewed commit: 7665985}

greptile-apps

_{9 files reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

greptile-apps · 2026-02-20T16:16:56Z

apps/ios/Sources/Model/NodeAppModel.swift

+        } catch {
+            self.watchReplyLogger.error(
+                "watch reply forwarding failed replyId=\(event.replyId, privacy: .public) error=\(error.localizedDescription, privacy: .public)")
+            self.queuedWatchReplies.insert(event, at: 0)


retry re-queues failed reply at front, but seenWatchReplyIds prevents re-processing

the retry logic inserts failed events at index 0, but the replyId remains in seenWatchReplyIds from the initial attempt, causing retries to be silently dropped in handleWatchQuickReply (line 2275-2279)

Suggested change

self.queuedWatchReplies.insert(event, at: 0)

self.seenWatchReplyIds.remove(event.replyId)

self.queuedWatchReplies.insert(event, at: 0)

Prompt To Fix With AI

This is a comment left during a code review. Path: apps/ios/Sources/Model/NodeAppModel.swift Line: 2324 Comment: retry re-queues failed reply at front, but `seenWatchReplyIds` prevents re-processing the retry logic inserts failed events at index 0, but the `replyId` remains in `seenWatchReplyIds` from the initial attempt, causing retries to be silently dropped in `handleWatchQuickReply` (line 2275-2279) ```suggestion self.seenWatchReplyIds.remove(event.replyId) self.queuedWatchReplies.insert(event, at: 0) ``` How can I resolve this? If you propose a fix, please make it concise.

@mbelinky

…anks @mbelinky

@mbelinky

…anks @mbelinky

mbelinky · 2026-02-20T16:39:19Z

Merged via squash.

Prepared head SHA: 3c2a01f
Merge commit: 738b011

Thanks @mbelinky!

@mbelinky