Background
MessageRouter.send(_:) (dictionary path) now always routes through
updateApplicationContext (serialized via a dedicated DispatchQueue), and the
interactive WCSession.sendMessage path was removed. See
Sources/SundialKitStream/MessageRouter.swift.
This is the correct default for the ContextEngine use case (latest-desired-state
snapshots, for which application context is correct in every reachability state)
and it sidesteps the double-resume crash a flapping link causes with
sendMessage's reply-expecting checked continuation.
The gap
Callers that previously relied on the low-latency interactive path
(ConnectivityObserver.sendMessage(_:) → WCSession.sendMessage when reachable)
no longer get immediate delivery — a time-critical command (e.g. "start workout
now") is now coalesced through application context. This is a silent behavioral
change with no compile-time signal.
Proposal
Offer an explicit opt-in for the interactive path for callers that genuinely need
immediate, reply-bearing delivery while reachable — e.g. a distinct API
(sendInteractive(_:)) or a transport option on the existing call — so the safe
application-context routing stays the default while low-latency delivery remains
available behind an explicit choice.
If we add it back, the implementation must guard the withCheckedThrowingContinuation
against a double-resume (a flapping link can fire sendMessage's error handler
twice), mirroring the ResumeOnce guard now used on the binary sendBinary path.
Context
Raised during the v1.0.0-alpha.3 PR review (finding F4). Deferred intentionally:
the current default is correct; this tracks the opt-out for interactive callers.
Background
MessageRouter.send(_:)(dictionary path) now always routes throughupdateApplicationContext(serialized via a dedicatedDispatchQueue), and theinteractive
WCSession.sendMessagepath was removed. SeeSources/SundialKitStream/MessageRouter.swift.This is the correct default for the
ContextEngineuse case (latest-desired-statesnapshots, for which application context is correct in every reachability state)
and it sidesteps the double-resume crash a flapping link causes with
sendMessage's reply-expecting checked continuation.The gap
Callers that previously relied on the low-latency interactive path
(
ConnectivityObserver.sendMessage(_:)→WCSession.sendMessagewhen reachable)no longer get immediate delivery — a time-critical command (e.g. "start workout
now") is now coalesced through application context. This is a silent behavioral
change with no compile-time signal.
Proposal
Offer an explicit opt-in for the interactive path for callers that genuinely need
immediate, reply-bearing delivery while reachable — e.g. a distinct API
(
sendInteractive(_:)) or a transport option on the existing call — so the safeapplication-context routing stays the default while low-latency delivery remains
available behind an explicit choice.
If we add it back, the implementation must guard the
withCheckedThrowingContinuationagainst a double-resume (a flapping link can fire
sendMessage's error handlertwice), mirroring the
ResumeOnceguard now used on the binarysendBinarypath.Context
Raised during the v1.0.0-alpha.3 PR review (finding F4). Deferred intentionally:
the current default is correct; this tracks the opt-out for interactive callers.