Will My Records Survive Losing and Restoring the Connection?

A checkmark that stays on screen is not confirmation that the server applied the change. This test used one synthetic checklist built with AI and prescribed storage and retry mechanisms. In all six cases (A1–A3, B1–B3), three edits remained on the device after stopping the test server on the same Mac, reopening the app, and applying a non-destructive v2 update; the final test-server records also matched. Only B updated while the edits were still pending. Whether the completion message appeared at the right moment could not be verified.

This is a conceptual illustration, not a test screenshot or evidence of successful sync.

The test ran on October 8, 2026, in a headless Chrome tab—without a visible browser window—on one Mac. Only the test server on that same Mac was stopped. The machine’s network settings were left alone, and an installed web app was not tested. These are per-criterion observations, not a success rate or a verdict on production use, mobile devices, or multiple devices.

What the sources say: connected does not mean delivered

MDN’s explanation of connection status says browsers use several clues to decide whether they are online. A local network connection can count as online even without Internet access. An online indicator does not prove that a particular server received anything.

The IndexedDB documentation describes a way to store structured data inside the browser. That local storage capability does not itself confirm receipt by the server.

Recorded observations: send first, or update while changes are pending

The app’s requirements specified device storage, a queue of pending changes, operation IDs that stay the same on retries, acknowledgement checks, and an update process that preserves records. The supplied server also had a mechanism to apply an operation only once, even if it received it again. This was not a test of whether AI would discover that architecture on its own. This experiment compared the screen, device storage, and server records separately. The browser’s online value remained true at every checkpoint while the server was stopped.

Each case started with a fresh browser profile and database holding a 10-item checklist, first loaded while the server was running. With the server stopped, the app was closed and reopened. The edits were made in order: check item 02, enter 우산 / umbrella (Korean and English for “umbrella”) in item 05, then check item 09. Reopening again checked whether the three edits and their pending operations remained on the device. Every case used the same app with mixed Korean and English text; these were not separate language tests.

• A1–A3: The server was restarted normally; sending finished before the app updated to v2.
• B1–B3: The server was restarted to serve app files but reject writes with HTTP 503. The app updated to v2 with all three operations still pending. When writes were allowed, the server was simultaneously set to apply the first operation—the item-02 check—but cut off its reply. Only B1 and B3 showed a failed request without a response followed by a distinct retry.

The v2 changes were a visible version label and an optional tag index added to storage without deleting records. The way the app and server exchanged data stayed unchanged. While the downloaded v2 waited to activate, the current version remained v1. After closing the app tabs and the separate read-only storage-checking page and reopening, the screen, running code, and storage structure reflected v2. In B, the three edits still remained on the device at that point, awaiting server confirmation.

The table reports the frozen criteria separately. “Pass” means only that the named criterion was met; the cells are not combined into a success rate. “Not reached” means the situation needed to judge that criterion did not arise. “Unverified” means the evidence was insufficient for a verdict. B2’s passes do not show recovery after a lost reply that the app itself detected. The next section explains why.

B2: the server recorded an aborted response followed by deduplication, but the browser showed one successful response. These passes do not establish a distinct retry for that aborted-response pair or recovery after an app-detected lost reply. The ID-reuse verdict also covers earlier failed or write-rejected retries. The freshness row covers checklist values and item count within the 2-second rule, not completion-message accuracy. Installation was not attempted and remains unverified. “No duplicate effects” means one observed application of each operation to server records under the supplied server.

Each case ended with 10 items, the three intended edits, one effect per operation, and 0 pending operations. The other seven items remained unchanged. A had no server deduplication event. Repeating a request is not itself a duplicate effect, and the contribution of the server’s deduplication mechanism was not measured separately. The retention result covers this profile’s short reopen and compatible update; it is not proof of a backup. Clearing site data, browser removal under storage pressure, crashes, and power loss were not tested. The allowances of 2 seconds for screen data and wording, and 30 seconds for automatic recovery and version activation, were rules chosen for this experiment, not standards.

The moments that could not be verified are part of the result

The English half of the bilingual status changed from “Saved on this device · 3 changes pending” to “Confirmed by server.” Status-message accuracy remains unverified in every case. A separate check of device storage confirmed that nothing was still waiting only after the first completion message: 60, 42, and 11 milliseconds later in A1, A2, and A3, and 42, 30, and 51 milliseconds later in B1, B2, and B3. The preceding device check still showed pending work. Recorded network-response times precede the first completion-message capture, but that does not establish that the device queue was already empty at that instant. The evidence establishes neither a false completion message nor an accurate one.

Two calibration runs—unscored trials before measurement—checked the test setup. The deliberate dropped reply did not always appear as intended. In calibration 1 and B2, the server cut off a response, yet the browser observation showed a normal response within a single request. This was an observation about the test apparatus. A hidden retry by the browser below the app is a strong possible explanation for calibration 1 only; the exact low-level cause was not established. Neither calibration 1 nor B2 counts as recovery after a lost reply that the app itself detected.

Before measurement, the test server’s connection-closing method was changed; app behavior and scoring rules stayed unchanged. Calibration 2 verified the conditions, and the test files were locked for measurement. Even so, B2 again showed a successful response. Passing calibration did not guarantee that every later case would expose the lost reply. B1 and B3 showed a failure without a response, followed by a distinct retry with the same ID and just one server effect. B2 retains the individual verdicts above but is not valid for the planned test of a lost reply that the app itself detects. Coverage of that condition is incomplete; calibration cases were not substituted for it.

My view: record “saved here” and “confirmed there” separately

While the server was stopped, the three changes were absent from it. In B1 and B3, however, the first operation was applied on the server while still pending on the device because its reply had not arrived. This app already distinguished device storage from server confirmation, but “pending” alone did not explain that difference. My suggestion is to note storage location, server application, and acknowledgement separately. The following card is for a test app using synthetic, non-sensitive data, not a procedure for resending records in a live account. Its effectiveness and beginner comprehension have not been tested.

Actual connection-failure condition / time:
Test note without personal data / checkbox / initial item count:
Message immediately after input / pending count:
Values / message / item count after closing and reopening the same app:
Values / message / item count after the connection returns:
If an update occurred, displayed pending counts before and after:
Kept on this device: what you observed, or unknown
Applied on the server: server records checked separately from the app screen, or unverified
Server reply confirmed: what you observed, or unknown
Questions for the builder, alongside your evidence:
  Where are pending changes stored? What confirms receipt?
  Do retries use the same ID? How do pending records survive an update?

The screen and item count alone cannot establish that the server applied no duplicate effects. If you can only see the screen, leave the server-application field unverified. The builder’s explanation cannot replace independent evidence either. Switching off Wi-Fi or recording results on another device creates different conditions from this experiment.

Untested or unverified areas include:

• Environment: installation and standalone mode, this same Chrome with a visible window, mobile devices and other browsers, real wireless or Internet outages, and Wi-Fi login pages. The calibration-1 retry explanation cannot be extended to these environments.
• App behavior: manual recovery, the first completion instant, B2’s intended lost-reply condition, sending after the app closes, and conflicts across devices, users, or tabs.
• Retention and operation: long-term retention, browser removal of stored data, backup restoration, crash and power-loss durability, security and permission isolation, production readiness, and hosting-provider performance.
• Generalization: ID schemes other than the one specified, a server without deduplication, AI builders’ general capabilities, reliability across apps, the card’s effectiveness, and reader comprehension.

The environment was macOS 27.0 build 26A428, Chrome 155.0.8059.39 (captured user agent: HeadlessChrome/155.0.0.0), and Playwright Core 1.62.1. Construction used a Codex/Astra AI coding session; the actual responding model was not independently confirmed, and token usage was unavailable. The verifier was assigned after construction. The coordinator executed the test, and a separate experiment-record writer rescored saved evidence. That rescore was not a rerun, and assigning the verifier later does not establish independent oversight of the original construction. Interpretation of the captured screen is Codex editorial judgment. A separately kept experiment record retains versions, inputs, files locked before measurement, and raw-evidence paths.

The six-case measurement span, from the first start to the last finish, was approximately 84 seconds. There were no new experiment charges (0 Korean won). That does not mean the existing subscriptions were free. Total labor, review and writing time, and precise usage-based costs were unavailable. What this record supports is the habit of asking where a change was saved in your own app—not a reliability guarantee for AI-built apps or progressive web apps (PWAs) in general.

AI assisted with research and drafting. The author reviewed the final manuscript and directed the revisions.