재시도와 오프라인 대체 처리

A timeout often clears on a second try. Treat transient errors as worth retrying, not as a final dead end for the user.

Only retry transient kinds like network timeouts. A parsing error will fail again every time, so retrying it just wastes effort.

Wrap the call in a small loop that tries a few times. If it finally succeeds, return Success; otherwise fall through to Failure.

Hammering instantly rarely helps. Add a growing delay between attempts so a struggling server gets room to recover.

Never loop forever. A hard max of two or three tries keeps the user from waiting endlessly on a truly down service.

When retries are exhausted, look in local storage. Showing slightly old data beats showing an empty, broken screen.

A friendly pattern is stale-while-revalidate: display cached data instantly, then quietly fetch fresh data in the background.

When you fall back to cache, set an offline flag in your state so the UI can show a subtle banner about stale content.

Because this runs in a suspend function, delays and retries read like simple sequential code, with no callbacks or threads to manage.

Respect cancellation: if the screen closes mid-retry, structured concurrency stops the loop so you never leak background work.

Callers just invoke loadWithRetry and get the best outcome: fresh data, cached data, or a clear Failure, all decided in shared code.

Think about which failures deserve another attempt.

You retried transient errors with backoff, capped attempts, fell back to cached data with an offline flag, and kept it cancellable in shared code. 🔄