Offline mobile retry

Problem Context

• The action originates from a phone, tablet, PWA, mobile webview, or native shell where connectivity, app lifecycle, OS background limits, battery, and metered data can change mid-task.
• Users may attach photos, scan codes, send messages, submit forms, save field records, check in, approve work, invite people, or perform payments while offline or intermittently connected.
• The app can store local payloads, queue requests, identify retryable failures, and distinguish foreground retry from background replay.
• Offline mobile retry sits near offline state, retry, sync state, pull to refresh, fallback path, error state, loading spinner, progress bar, draft state, and conflict resolution.

Selection Rules

• Choose offline mobile retry when a mobile action should be preserved and retried after connection loss, flaky network, app backgrounding, or policy-limited connectivity.
• Show whether the action is saved locally, queued, waiting for connection, retrying in foreground, eligible for background retry, paused, failed, expired, or accepted remotely.
• Keep the original request identity, object, attachment list, timestamp, retry count, and idempotency reference visible or recoverable for side-effecting actions.
• Offer manual Retry now when users need control, but disable duplicate submit while the same queued action is pending or retrying.
• Pause or explain retry when the network is metered, battery saver is active, Wi-Fi-only upload is required, captive portal blocks requests, account sign-in expired, or OS background sync is unavailable.
• Use offline state when the main question is what works while disconnected, not one queued mobile action's retry lifecycle.
• Use retry when a single failed operation is retryable without mobile offline, background, or queue constraints.
• Use sync state when several local and remote copies are reconciling and users need accepted, partial, failed, paused, or conflict status across a queue.
• Use pull to refresh for user-requested content refresh, not for hidden retry of pending submissions.
• Use fallback path when retry is exhausted, unsafe, non-retryable, or requires another channel such as export, manual entry, call support, or later return.

Required States

• Online successful action state.
• No connection at submit state with local queue confirmation.
• Queued mobile action state with request ID, timestamp, and stored payload summary.
• Manual retry-ready state that preserves the original action and disables duplicate submit.
• Retry pending state with attempt count and duplicate guard.
• Background retry eligible and background retry unavailable states.
• App backgrounded or returned-to-foreground state with queue still visible.
• Metered data, Wi-Fi-only, low battery, and battery saver paused states.
• Captive portal or server unreachable state distinct from device offline.
• Sign-in expired or permission changed state that routes to recovery before retry.
• Attachment upload failed, partial upload, and retry attachment states.
• Retry succeeded, failed again, retry exhausted, cancelled, expired, and conflict-needs-review states.

Interaction Contract

• The UI never reports server success for a mobile action that is only saved locally or queued.
• Retry repeats the preserved queued action rather than creating a new submission unless users explicitly duplicate or edit it.
• A pending queued action suppresses duplicate Submit, Send, Upload, Pay, Check in, or Approve controls for the same scope.
• Automatic background retry respects OS support, connectivity, battery, metered-data, authentication, idempotency, and retry-limit constraints.
• Manual retry reports pending, succeeded, failed again, paused, sign-in required, conflict, exhausted, or fallback outcome.
• Queued work remains visible after app restart, background return, network change, and page refresh until users resolve or cancel it.
• Side-effecting operations expose enough identity for deduplication, support, and user trust without leaking sensitive payload details.

Implementation Checklist

• Classify mobile actions by retry safety, side effects, idempotency needs, attachment size, credential requirements, and allowed network conditions.
• Persist queued payloads in native storage, IndexedDB, Cache API, service-worker queue, upload manager, or another durable local store with stable IDs.
• Store request ID, retry count, last attempt, next retry time, backoff rule, payload summary, attachment status, and user-visible object name.
• Distinguish device offline, server unreachable, captive portal, timeout, sign-in expired, validation failure, conflict, and policy pause.
• Use background sync or native background transfer only when the UI can show eligibility, retention, retry limits, and foreground fallback.
• Disable duplicate submit while a matching queued action exists, and provide cancel, edit, export, retry now, retry on Wi-Fi, and fallback actions as appropriate.
• Announce meaningful queue transitions such as queued, retrying, sent, failed, paused, sign-in required, and conflict needs review.
• Test airplane mode, tunnel or basement loss, flaky connection, captive portal, low battery, metered data, app kill/restart, background return, duplicate tap, attachment failure, auth expiry, and server conflict.

Common Generated-UI Mistakes

• Showing a success toast for an offline submission that is only queued.
• Hiding the queue after users leave the screen or background the app.
• Letting Submit create a second request while a matching queued request is pending.
• Retrying every few seconds on unstable mobile networks with no backoff or pause.
• Treating captive portal, expired auth, validation failure, and offline as the same retryable state.
• Uploading large attachments on metered data without user control.
• Clearing attachments after a background retry fails.
• Using pull to refresh as the only way to recover queued saves or uploads.

Critique Questions

• What exact mobile action is queued, and where is it saved until retry?
• What proves the server accepted the action, and what visible state exists before that proof?
• What prevents duplicate records, messages, payments, uploads, approvals, or check-ins if users tap again?
• Will retry happen in the background, only in foreground, only on Wi-Fi, or only after sign-in or user action?
• How are metered data, low battery, captive portal, auth expiry, partial attachments, and conflicts represented?
• What is the fallback when retry is exhausted, unsafe, expired, or unsupported by the OS?