Network-Loss Testing for Offline and Hybrid AI

Direct answer

A network-loss test asks what happens when connectivity changes during a specific workflow step. It is different from an airplane-mode test of an entirely local task: a hybrid workflow may send a request, retrieve supporting data, or synchronize a result. If the network disappears between these stages, the application needs to identify which step was local, which was remote, whether a request might have reached the service, and what the user should do next. A cached screen or previously generated response is not evidence that a fresh inference completed offline. Map the data path before injecting failure. List every network-capable component, request purpose, data category, endpoint owner, and failure policy. Do not assume that a final AI call is the only network boundary; analytics, model/config checks, remote retrieval, image upload, and result sync may be separate. If privacy facts say a task stays on device, test that actual path and do not route around a failed local engine to a cloud endpoint without a separate user-visible product decision. This article covers interruption testing, not approval to send data remotely. Choose fault points that have different semantics. Connectivity can disappear before request creation, during upload, after the server accepts a request but before the response arrives, during a remote retrieval, or while synchronizing an already computed local result. A timeout cannot always reveal whether the server processed a request. Use an idempotency key or operation identity where supported by the application's contract, and ensure a retry cannot duplicate a side effect. If the integration does not expose such evidence, show an uncertain state and ask before resubmitting sensitive work. Separate connectivity observation from reachability. Android's network APIs can report available transports and capabilities, but a network being present does not prove a particular endpoint is reachable or authorized. Conversely, a short outage may not be visible at the moment a UI checks the status. The operation itself must handle I/O failure and cancellation. Do not write a global “internet available” Boolean as a permanent authorization to start a task. Record the state relevant to the operation and the first failed boundary. Test user-visible transitions as well as exceptions. A task may remain locally useful, pause and resume a safe transfer, be cancelled, or become uncertain. Define which case applies before running the test. Show whether local preprocessing or inference completed, whether remote processing was attempted, and whether a result is provisional. Keep partial state so the next screen does not claim success after a dropped response. Retry should be explicit and bounded; avoid rapid automatic loops that drain battery or duplicate requests. Make fixtures safe and controlled. Use synthetic request bodies, a test endpoint, or a local network proxy to cut connectivity at a chosen boundary. Never use a real user's photo, transcript, or health record as fault-injection data. Record the operation ID, boundary, request state, connectivity event, cancellation result, and recovery choice—not request content. Verify that restoring connectivity does not automatically upload content the user thought had been discarded. The evidence should distinguish four statements: the app completed a task with no network route; the app completed local preprocessing but not remote work; the remote request may have been accepted but its response was lost; or the task failed before any remote request. These outcomes should not be collapsed into “offline mode works.” The project's ARCH-02 and privacy facts require network behavior to be bounded to the actual pipeline. A test establishes only the specific app build, endpoint, data class, operation stage, and retry policy exercised; it does not prove every feature is offline or secure. After the test, inspect request and error traces with content redacted. If a request may have reached the server, the recovery UI should avoid pretending that it was never sent. If a local result is complete but sync failed, preserve it locally under a declared retention policy and offer sync later. If the request body was never uploaded, do not unnecessarily discard completed local work. Keeping these states distinct protects correctness and user trust, while making incident review possible without collecting private payloads.

A hybrid document assistant loses connectivity after local parsing

The app has parsed a user-selected document locally and is about to request an optional remote lookup. The connection drops after upload begins, and the client cannot tell whether the service received it.

Decision

Mark the remote operation uncertain, keep local work distinct, avoid an automatic duplicate upload, and ask before a retry that may resend content.

Expected outcome

The UI reports what was processed locally and what may have crossed the network, without calling cached data a fresh offline answer.

Evidence to collect

The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:

• Routing table
• Fault injection points
• User-visible recovery

A release claim is valid only for the recorded configuration and acceptance set. Generalization requires additional records.

Implementation workflow

1. Inventory the workflow boundaries. List local preprocessing, local inference, remote calls, retrieval, analytics, and synchronization. Record data categories, purpose, endpoint, and user-facing failure behavior for each.
2. Define retry semantics for every request. Classify a request as not started, definitely sent, response received, or uncertain. Use stable operation identity where the app contract supports it, and prevent automatic duplicate side effects.
3. Inject loss at controlled stages. Cut connectivity before request, during upload, after possible server acceptance, during retrieval, and during result sync. Use synthetic payloads and a test endpoint or controlled proxy.
4. Verify local and remote states separately. Assert whether local preprocessing or inference completed, whether remote work was attempted, and which outputs are provisional. Preserve completed local work without labeling it a fresh offline result.
5. Restore connectivity and test recovery. Confirm no discarded payload is silently uploaded on reconnection. Require an explicit bounded retry when request receipt is uncertain and redact content from operational logs.

Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.

Acceptance criteria

• Every network boundary in the tested pipeline has a declared purpose, data class, and failure policy.
• The app distinguishes definitely unsent, possibly accepted, completed, cancelled, and locally completed states.
• Reconnection does not automatically resend user content that was cancelled or shown as discarded.
• Test evidence uses synthetic content and records operation stages without logging payloads.

Decision table

Failure patterns to prevent

• Silent cloud retry
• Calling cached UI offline functionality

Also prevent silent fallback, unpinned artifacts, missing cancellation, and conclusions that combine unlike configurations. Store unsuccessful runs alongside successful ones.

Minimum reproducibility record

Release checklist

• ☐ The primary query is answered without an unsupported number.
• ☐ Every artifact and runtime is pinned.
• ☐ The representative task and failure policy are explicit.
• ☐ Lifecycle, cancellation, cleanup, and fallback are tested.
• ☐ User-content and network boundaries are documented.
• ☐ Result wording applies only to the recorded configuration.
• ☐ The page links to raw method or evidence when results are added.

Sources and related evidence

• On-device and hybrid routing boundary
• Read Android network state and capabilities
• Manage network usage in Android apps

Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.

Frequently asked questions