From fe41226ef5fbb88c8daf5c6806e978f7c980ff33 Mon Sep 17 00:00:00 2001 From: Jinwoo-H Date: Tue, 22 Sep 2026 22:46:32 -0400 Subject: [PATCH] docs(mobile): state the on-settle reason that holds for pipelined bundle reads Claude-Session: https://claude.ai/code/session_01JNnE9qzUZMMnqpZWCqM3nb --- mobile/src/transport/mobile-web-bundle-operations.ts | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/mobile/src/transport/mobile-web-bundle-operations.ts b/mobile/src/transport/mobile-web-bundle-operations.ts index b44b09ef05c..e11f6447214 100644 --- a/mobile/src/transport/mobile-web-bundle-operations.ts +++ b/mobile/src/transport/mobile-web-bundle-operations.ts @@ -18,8 +18,8 @@ import { rpcResultVariant } from './rpc-operation-result-reader' // The reads that hand a paired phone the desktop's mobile web bundle. All are // `require-result-or-throw`: there is no partial success here, and a salvage policy would produce a // half-bundle that fails a hash check much later, far from the cause. All settle at `on-settle`, -// because each reply is acted on before the next request is built — the manifest decides which -// windows to read, and a chunk or range reply decides whether its asset is whole. +// because each reply is interpreted as soon as it lands and waits on no sibling: the manifest before +// any window is planned, and each chunk or range while the other reads are still in flight. /** The whole manifest plus the chunk size the host will serve it at. */ export const mobileWebBundleManifestRead = defineRpcOperation({