Expo Updates: Ensuring Idempotent Retries Without Duplicate Bundle Writes

Goal: guarantee that a retry triggered by a transient network error does not cause the Expo Updates client to write the same JavaScript bundle more than once to local storage.

The current mechanism relies on comparing the hash returned by the server with a locally stored hash and using a persistent store (expo‑updates) to skip re‑download when the hashes match. However, early SDK releases may perform a case‑sensitive hash comparison, which can turn a 304‑equivalent response into an unnecessary re‑fetch. Additionally, if a network interruption leaves the locally stored hash stale, the client may attempt a redundant download and cause UI flicker.

Does the Expo Updates client treat hash comparison as case‑insensitive in SDK 49 and later? How does the persistent store update when the server returns a 304 Not Modified? What safeguards prevent duplicate writes if the local hash becomes stale after a transient failure?