Skip to content

v2.0.2

Pre-release
Pre-release

Choose a tag to compare

View all tags
@github-actions github-actions released this 22 Jul 04:31
v2.0.2
9491cea

v2.0.2 - Durable Browser Upload Recovery

Development prerelease. This release is published from dev, may receive
rapid follow-up changes, and is not selected by the default latest image.

Summary

v2.0.2 makes browser upload work recoverable across refreshes, page navigation,
tab closure, and transient network failures. Sources and V2 processing results
are stored in a per-user IndexedDB queue before network side effects begin, and
the client reconciles durable work with server upload-session state when the
upload page is opened again.

There are no database migrations and no server upload-protocol changes in this
release.

Changes

Durable browser queue

  • Added an IndexedDB queue keyed by user and queue ID, with the source file,
    SHA-256 source fingerprint, processing recipe, attempt number, visibility,
    upload-session identity, and retry state stored together.
  • Requests persistent browser storage on a best-effort basis and checks the
    available quota while reserving at least 32 MiB or 10 percent of the quota.
  • Falls back to a clearly labelled current-tab-only item when durable storage is
    unavailable instead of blocking every upload.
  • Applies a 24-hour retention boundary and lazy expiry cleanup. Completed or
    explicitly removed items are deleted immediately when storage is available.
  • Removes persisted processed derivatives after the server enters processing;
    the source remains bounded by completion, explicit removal, or expiry.

Crash-safe V2 upload flow

  • Upload-session ID and expiry are durably recorded before the first part PUT.
  • Persisted processed WebP parts can be reused after interruption without
    decoding and encoding the source again when the recipe still matches.
  • Refresh, navigation, tab closure, and authentication boundaries abort local
    work without implicitly cancelling a recoverable server session.
  • Only explicit removal requests server-side cancellation.
  • Existing idempotency keys remain derived from the queue ID and authoritative
    attempt, preventing an interrupted attempt from publishing twice.

Server reconciliation

  • Reconciles active queue entries through the batch upload-status endpoint and
    recursively isolates missing IDs when the server reports a mixed 4043 batch.
  • Completes already-published entries locally, resumes non-expired part uploads,
    polls sessions already processing, and starts a new idempotent attempt only
    when the previous session is missing or expired.
  • Pauses the queue without destructive state changes when status reconciliation
    is temporarily unavailable.
  • Treats an interrupted legacy V1 request as an unknown, non-retryable outcome
    and asks the user to check My Images before removing or uploading it again.

Multi-tab and account isolation

  • Added renewable per-run leases and transaction-level ownership checks so only
    one tab can mutate a durable queue item at a time.
  • Manual retries are prepared atomically from the authoritative stored attempt
    and upload ID, fencing stale UI state after a lease handoff.
  • Authentication generation guards stop stale login or profile requests from
    restoring a previous account, and login, logout, password change, and remote
    authentication events clear queue data outside the active user boundary.
  • Added localized saving, paused, recovery-ready, current-tab-only, storage, and
    legacy-outcome messages in English, Simplified Chinese, and Japanese.

Dependencies

  • Added exact runtime dependency idb 8.0.3.
  • Added exact test dependency fake-indexeddb 6.2.5.

Compatibility and Resource Behavior

  • The queue uses IndexedDB, Web Crypto SHA-256, Blob, and File APIs supported by
    the V2 browser matrix, including Chromium 93+ and the deployed iOS WebKit 605
    family.
  • Browser image processing remains serial. Queue orchestration admits two items
    concurrently and allows at most four active upload sessions in one tab,
    leaving capacity for recovery or another tab under the server's per-user
    session limit.
  • Server-side image processing, storage layout, recipe 2.0.0, and fixed WebP
    variants are unchanged.

Verification

  • Frontend Vitest: 17 test files, 131 tests passed.
  • ESLint: passed.
  • TypeScript project and Vite production build: passed.
  • Python requirements lock verification: passed.
  • GitBook documentation and translation source-hash verification: passed.
  • The existing wasm-vips dependency direct-eval warning remains unchanged and
    does not fail the build.

Installation

Development images must be pulled explicitly:

docker pull jaykserks/summerain:dev-v2.0.2

Equivalent exact development tag:

jaykserks/summerain:dev-2.0.2

The moving dev tag also points to the newest successful development build.
latest, main, and stable semantic-version aliases are not changed by this
release.

Known Limitations

  • Browsers may evict durable queue data when persistent-storage permission is
    not granted; affected entries are labelled as current-tab-only when the
    initial durable write fails.
  • The 24-hour cleanup is lazy and runs when queue storage is accessed, so expired
    browser data can remain until the upload page is opened again.
  • Legacy V1 uploads do not expose a queryable session identity. An interrupted
    V1 request therefore requires manual confirmation in My Images.
  • Animated image support remains planned for a later release.
  • Real-device acceptance for the supported Chrome and iOS browser matrix is a
    deployment validation step and is not represented by jsdom unit tests.
Assets 2
Loading