Persistence & reload-resume

A local export lives entirely in tab memory — there's nothing to save, so reloading mid-export simply loses it (see How Eazip works). A cloud export is different: the job runs on the server, so @eazip/react persists just enough to reattach to it after a reload.

What gets saved

The moment a cloud task's session exists — sessionId + clientSecret, the same values job.getSnapshot().session exposes in @eazip/core — the store writes a versioned envelope to localStorage under the key eazip-tray-v1: task state, zip metadata, skippedCount, whether a download already started, and (when the task came from a plain download({ files, publicKey }) call) enough of the original request to support retry(). Sessions started via a createSession callback persist the same way, minus the retryable request — see Backend-created sessions.

Nothing is written for local tasks: their result is a set of in-memory Blobs, which can't be serialized into localStorage — persisting a local task's metadata without the actual zip bytes would just be a misleading ghost entry, so the store skips it entirely.

Hydration

On mount, useEazip()/<EazipTray /> read the envelope back and restore the task — from an effect only, never during render, so server-rendered and client-rendered output always match on first paint. If the saved task was still 'processing', hydration calls resumeZip() immediately and polling picks up where it left off; if it had already finished, the saved zip metadata (including any downloadUrl) is shown as-is. A task whose expiresAt has already passed by the time you reload comes back as 'expired' instead.

Opting out

<EazipProvider config={{ persist: false }}>
  <App />
</EazipProvider>

persist: false (via EazipProvider's config) disables reads and writes entirely. storageKey overrides the default 'eazip-tray-v1' key — set it per app if multiple Eazip-powered apps might share an origin.