Files

T

feat(ui): label streamed installs as not shareable

NEXT_STEPS item 7 needed the installed-but-not-downloaded state to be
clear to users. Keep streamed installs in the installed visual state so
sorting, filters, and the primary Play action stay unchanged, but make the
sharing limitation visible in the UI.

Cards now label that state as `Not shareable`, while the detail modal
status says `Installed, not shareable`. Downloaded-and-installed games
keep the normal `Installed` wording.

Test Plan:
- just frontend-test
- just build
- git diff --check
- git diff --cached --check

Refs: NEXT_STEPS.md item 7

2026-06-07 22:29:26 +02:00

3.2 KiB

Raw Blame History

Streamed Install Next Steps

I’d treat the prototype as proof of the hard part: “can we stream archive-derived install bytes into local/ without making the receiver a source?” Yes. Next I’d harden the pieces that decide whether this is product-ready.

Done — Move from CLI-only to real app integration

The GUI now has an explicit “Low disk install” action in the game detail modal for remote-only games. The Tauri backend queues that path through stream_install_game, injects the shared external unrar stream provider, and hands fetched file details to StreamInstallGame instead of the normal download command.
Done — Replace per-file unrar p with a final archive provider

The shared external unrar stream provider now runs unrar lt once for the archive metadata and one sequential unrar p pass per archive for payload bytes. It frames directories, file starts, file chunks, and file ends from the technical listing, so CLI and GUI callers use one purpose-built provider instead of a per-file extraction loop.
Done — Handle solid archives deliberately

The provider exposes the RAR solid flag in ArchiveBegin and always uses one sequential payload pass per archive, which is the safe path for solid archives. S41 now verifies a real solid RAR fixture through the Docker peer-cli flow, including local-only final state, absent root archive/sentinel, byte count, and extracted payload SHA-256 hashes.
Done — Decide the integrity model

Streamed installs intentionally verify against sender archive metadata for now: each file must match the RAR-advertised size and CRC32. That catches transport corruption, truncation, and provider bugs, but does not claim malicious-peer protection. Trusted content remains a separate catalog schema step: add catalog-owned archive or extracted-file SHA-256 hashes, then verify those at the receiver before commit.
Done — Upgrade retry/resume semantics

Streamed install attempts now use the same majority-validated peer set as normal downloads, and each failed attempt rolls back its staging transaction before trying the next peer. S42 pins the policy: retry the whole stream from another validated peer, keep no partial files across attempts, and do not add byte-offset resume until there is a strong reason.
Done — Expand scenario coverage

S43-S47 cover the remaining streamed-install edges: already-installed rejection, corrupt archive rollback, sender disconnect mid-stream, receiver cancel mid-stream, and multi-archive .eti roots streamed in sorted order. The peer-cli harness now exposes cancel-download so cancellation scenarios exercise the same runtime path as the GUI.
Done — Clean product semantics

The UI now keeps streamed installs in the installed visual state while making the sharing limitation explicit: cards show Not shareable, and the detail modal status shows Installed, not shareable. Downloaded-and-installed games keep the normal Installed label.

My recommended next slice: make the provider abstraction final-ish, then implement a real one-pass provider. Everything else builds cleanly on that.

3.2 KiB Raw Blame History Unescape Escape

Streamed Install Next Steps

3.2 KiB

Raw Blame History