--- title: Building State That Survives a Bad Network description: Optimistic updates, retry semantics and recovery after a dropped connection, designed for the train tunnel rather than the office wifi you develop on. canonical: https://www.hire-web-dev.com/journal/state-on-bad-networks/ section: Journal updated: 2026-09-11 author: SumanKumar Phuyal site: hire-web-dev.com note: >- Generated from the page of record at the canonical URL above. The four case studies are placeholder work and their metrics were never measured; imagery is AI-generated concept art. See https://www.hire-web-dev.com/disclosure/. --- # STATE THAT SURVIVES A BAD NETWORK Most interfaces are built as though requests succeed quickly. They usually do, which is exactly why the failure paths are where the embarrassing bugs live. ## The assumption to abandon Development happens on a fast, stable connection where requests come back in forty milliseconds and essentially never fail. Real use includes a train tunnel, a congested conference network, and a phone switching from wifi to cellular mid-submit. The code path where a request takes eleven seconds and then fails is not an edge case — on mobile it's a regular Tuesday. ## Three patterns that help First, model the request as a state machine rather than a set of booleans. Idle, pending, succeeded, failed, and — importantly — pending-after-failure for a retry. A discriminated union makes contradictory combinations impossible to represent, which matters because "loading and errored" is a state real code produces accidentally and no designer ever drew. Second, never discard user input optimistically. If someone spent four minutes on a form and the submit fails, their text must still be there. That sounds obvious and is violated constantly, usually because the component unmounted on submit or the store was cleared before the response arrived. Third, make retry deliberate rather than automatic and invisible. Silent retries on a non-idempotent request produce duplicate orders, and I've seen exactly that. Show the failure, offer the retry, keep the payload. ## How to actually find these Throttle your own connection and use your product for a day with a two-second latency and a five per cent failure rate injected. It's an unpleasant day and it surfaces more genuine bugs than a week of feature work. Every project where I've done this has produced at least one finding that would have been a support ticket within a month. ## Key facts - Entry: 06 - Subject: State management - Context: Mobile, real conditions - Theme: Failure paths ## Patterns - Model: State machine, not booleans - Preserve: User input always - Retry: Deliberate, not silent - Find them: Throttle and use it ## Topics STATE MACHINES, OFFLINE, RETRY, IDEMPOTENCY, THROTTLING ## Image ![Dense starburst of orange, blue and violet particles, application state scattering and reassembling](https://www.hire-web-dev.com/assets/img/offline-state-recovery-particle-starburst.jpg)