ddidderr/lanspread
1
0
Fork 0
Code Issues 6 Pull Requests Actions Packages Projects Releases Wiki Activity

test(peer-cli): verify protocol 8 transfer lifecycle

Browse Source 
Replace legacy metadata and relay expectations with current protocol-8 JSONL
assertions. Scenarios now bind every source to authenticated PeerId and exact
ContentId, prove typed attempt lifecycle order, and fence cancellation,
quarantine, rollback, republishing, and peer-departure outcomes against vacuous
success.

Isolated topologies distinguish direct author pulls from relay and ambient mDNS
substitution. The run log records focused diagnostics and the final fresh-image
S1-S49 acceptance result without presenting Docker-host throughput as a
representative external-LAN measurement.

Test Plan:
- `LANSPREAD_S37_MIN_MIB_PER_S=100 just peer-cli-tests` -- passed S1-S49
- S37 -- passed 2,147,483,656 bytes in 17 chunks at 551.10 MiB/s
- `python3 -m py_compile crates/lanspread-peer-cli/scripts/run_extended_scenarios.py` -- passed
- `ruff check --select F,E9 crates/lanspread-peer-cli/scripts/run_extended_scenarios.py` -- passed
- `git diff --cached --check` -- passed
This commit is contained in:
ddidderr
2026-08-10 14:00:03 +02:00
parent 71dbf27d8b
commit 4a1b08db98
3 changed files with 2441 additions and 515 deletions
Download Patch File Download Diff File Expand all files Collapse all files
organize/testing/PEER_CLI_SCENARIOS.md
+280 -114
View File
@@ -6,77 +6,80 @@ for deterministic local runs; mDNS/macvlan remains an environment smoke path.
## Scenario Matrix
| ID | Scenario | Setup | Expected result |
| --- | ------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| S1 | Startup scan | Start one peer with `fixture-alpha`. | Peer emits `local-peer-ready` and `local-library-changed`; catalog fixture games are `downloaded=true`, `installed=false`, `availability=Ready`. |
| S2 | Direct connect handshake | Start alpha and bravo, send alpha `connect` to bravo's ready address. | Both peers record one remote peer, no self-peer entry appears, and each peer receives the other's library. |
| S3 | Remote aggregation | Empty client connects to alpha and bravo. | `list-games` shows remote-only games once; shared `ggoo` has `peer_count=2`, unique games have `peer_count=1`. |
| S4 | Single-source download, no install | Empty client connected to bravo downloads `bfbc2` with `install=false`. | Client emits `got-game-files`, `download-begin`, `download-finished`, then local `bfbc2` is `downloaded=true`, `installed=false`; root files exist and `local/` does not. |
| S5 | Auto-install download | Empty client connected to bravo downloads `cnctw` with default install. | Download finishes, install begins and finishes, and local `cnctw` is `downloaded=true`, `installed=true` with `local/fixture-payload.txt`. |
| S6 | Manual install and uninstall | After S4, client sends `install bfbc2`, then `uninstall bfbc2`. | Install marks `bfbc2` installed and creates `local/`; uninstall removes `local/` while preserving downloaded root files. |
| S7 | Duplicate-source majority download | Empty client connects to alpha and bravo, then downloads shared `ggoo`. | Metadata from both peers validates by majority/plurality, download completes once, and installed state matches the install flag. |
| S8 | Ambiguous metadata rejection | Two peers advertise the same game/version with conflicting file sizes. | Download fails with a `download-failed` event; no committed `version.ini` is left for the target game. |
| S9 | Missing game | Client asks for a game none of its peers can serve. | CLI reports a deterministic command failure and emits `no-peers-have-game`; no local files are created. |
| S10 | Shutdown and goodbye cleanup | Alpha and bravo are connected, then bravo shuts down. | Alpha receives peer loss/removal and remote games from bravo disappear. |
| S11 | Same identity reconnect | Bravo restarts with the same state dir (the OS assigns an ephemeral listener port that usually, but not necessarily, differs), then alpha connects again. | Alpha has exactly one bravo peer entry reusing the same peer ID, not a duplicate identity, at whatever address bravo now advertises. |
| S12 | Transfer serving gates | A peer has a non-catalog, missing-sentinel, active-operation, or `local/` path request. | The serving peer declines metadata/data; covered by unit tests where timing is too small for a stable CLI race test. |
| S13 | Exact transferred-file equality | Repeat small and large downloads, then compare every transferred regular file against its source with SHA-256 manifests. | Source and receiver manifests match exactly for each transferred file; no extra or missing files appear in the downloaded game root. |
| S14 | Large multi-peer chunked download | A source advertises a synthetic catalog game whose `.eti` is a sparse file of `4 * CHUNK_SIZE` (four 128 MiB chunks). A second peer downloads it, then a third peer downloads it from both peers. | The third peer's downloaded files match the source by SHA-256; `download-chunk-finished` shows the `.eti` split across exactly both peers, all four chunks accounted for, and the per-peer byte totals balanced within one `CHUNK_SIZE` (a fair 2+2 split; a 3+1 imbalance would trip the check). |
| S15 | Catalog-version skew | Three peers advertise the same catalog game ID. Peers A and B have stale `version.ini` values; peer C has the catalog's expected version. An empty client connects to all three and downloads the game with `install=false`. | `list-games` shows one row for the game with `peer_count=1` and the catalog `eti_game_version`. The `got-game-files` descriptor set and transfer source are peer C only; no chunks come from A or B. The receiver's `version.ini` and SHA-256 manifest match C exactly. |
| S16 | Catalog-version fanout with stale peers present | Peer A has a stale version of a game. Peers B and C both advertise the catalog version with matching manifests; the `.eti` is inflated to `2 * CHUNK_SIZE` so it can fan out. | The aggregated row counts only catalog-version ready peers. The `.eti` chunks split across exactly B and C; peer A is not listed as downloadable and contributes no manifest vote or file chunks. |
| S17 | Catalog-version conflict rejection | Peer A has a stale version. Peers B and C both advertise the catalog version, but their file sizes conflict. | Validation considers only the catalog-version peers, so A cannot rescue the majority. The download fails with `download-failed`, and no committed target `version.ini` remains. |
| S18 | Mid-download source drop with redundancy | Client downloads a large shared multi-chunk game (sparse `4 * CHUNK_SIZE`, so both peers are assigned `.eti` chunks) from two ready peers, then one source is killed right after the download has begun. | The download survives the source kill: it finishes, no `download-failed` is emitted over the whole download window, every byte is delivered (chunk totals sum to the file size) with the survivor serving part of it, and the receiver's files match the source by diff or SHA-256. (Retry-onto-survivor is the mechanism that makes this possible, exercised when the kill interrupts an unfinished chunk, but it is not asserted because the kill timing cannot be forced; the per-source split is likewise not asserted.) |
| S19 | Mid-download sole-source drop | Client downloads a large multi-chunk game (sparse `4 * CHUNK_SIZE`) from one source, then that source is force-killed immediately after `download-begin`. An individual chunk may complete before the kill lands, but the full multi-chunk download cannot, so the failure is deterministic on a fast LAN. | The download emits a terminal failure (`download-failed`, or `download-peers-gone` when the sole source vanishes) and no `download-finished`; no committed target `version.ini` remains; any partial payload is not advertised as ready; active operation state clears so a retry is possible. |
| S20 | Receiver write failure | Client downloads a large game into a constrained `/games` filesystem. | The download fails deterministically, no committed `version.ini` is advertised, and active operation state clears so the peer can retry later. |
| S21 | Add-game propagation | Two connected peers are running; one peer gains a new catalog game root through a completed download or an external drop. | The other peer receives a library update without reconnecting, and `list-games` shows the new remote game under the existing peer. |
| S22 | Remove-game propagation | Two connected peers are running; one peer loses a previously advertised game root. | The other peer receives a library update without dropping the peer, and `list-games` no longer shows that remote game. |
| S23 | Version bump propagation | Two connected peers are running; one peer's ready game root starts with a stale `version.ini`, then changes to the catalog version. | The other peer receives a library update without reconnecting; the stale row is absent before the change, then the catalog-version game appears as downloadable. |
| S24 | Two clients pull from one source | Two empty clients connect to the same source and download the same large game concurrently. | Both downloads finish, both receivers match the source by diff or SHA-256, and the source remains responsive. |
| S25 | One client downloads two games concurrently | One client connected to a source issues two different `download` commands without waiting for the first to finish. | Both operations may run in parallel; both eventually finish, each game reaches the requested install state, and each transferred root matches its source. |
| S26 | Same-game duplicate download rejection | A client starts downloading a game, then issues a second `download` command for the same game while the first operation is active. | The second request is rejected deterministically as an operation-in-progress condition; the first download is not corrupted and still reaches its documented final state. |
| S27 | Self-connect rejection | A peer sends `connect` to its own advertised listener address. | The CLI command fails cleanly (CLI-level guard), no self-peer entry is created, and the peer remains responsive. The protocol-level guard (a hello whose `peer_id` equals the local id is acknowledged but never recorded) is covered by the `handshake::tests::inbound_hello_from_self_is_ignored` unit test, which the CLI string-compare never reaches. |
| S28 | Address change without identity change | A known peer is rediscovered with the same peer ID and a different listener address while its library is still known. | The peer record updates in place to the new address, the existing library stays attached to that peer ID, and no duplicate peer entry appears. This is covered with a deterministic unit-level check until the CLI can rebind a live listener without restart. |
| S29 | Empty-library peer participates | A peer with no games connects into the mesh. | Other peers list it as a peer with zero games; it can receive a download, advertise the new game without restart, and become a source. |
| S30 | 5+ peer mesh aggregation | Five peers advertise partially overlapping catalog games with a mix of unique and shared catalog-version games; a sixth client connects to all five. | The client shows one row per game ID, correct catalog-version ready-source `peer_count`, catalog `eti_game_version`, no duplicates, and no self entries. |
| S31 | Bootstrapped peer becomes source in same session | An empty client downloads a game from a source, the original source shuts down, then a fresh third peer downloads the same game from the bootstrapped client. | The third peer's files match the original source by diff or SHA-256, proving downloaded files become servable without restart. |
| S32 | Reinstall after uninstall | A downloaded game is installed, uninstalled, then installed again without another download. | `local/` is recreated from preserved root files, no transfer events occur during reinstall, and the game returns to `installed=true`. |
| S33 | Install after external root mutation | A downloaded game root is externally mutated before `install` is issued. | The CLI fixture installer installs from the current root bytes. The resulting `local/fixture-payload.txt` must match the mutated archive bytes exactly. |
| S34 | Many-small-files game without `.eti` | A catalog game root contains `version.ini` plus many small regular files and no archive. | Download with `install=false` transfers every file, chunk events are coherent for small files, and source/receiver manifests match exactly. |
| S35 | Unknown game ID from remote peer | A remote peer advertises a game ID that is not in the receiver's catalog. | The receiver does not list the unknown game as downloadable, download attempts fail deterministically, and no local files are created. |
| S36 | Catalog singleton beats stale majority | Five peers advertise one game; one peer has the catalog version and four peers have stale versions. | `list-games` reports `peer_count=1` and the catalog `eti_game_version`; all descriptors and chunks come from the singleton catalog-version peer, while stale peers remain hidden and contribute zero bytes. |
| S37 | Single-source download throughput | A source peer advertises a temporary catalog game with one sparse `2 GiB` `.eti`; an empty client downloads it with `install=false`. | The client emits `download-finished` with throughput measurements (`bytes`, `duration_ms`, `mib_per_s`, `mbit_per_s`), and the downloaded archive size matches the source. |
| S38 | First-play launch-setting stamping | `fixture-persona/css` ships a real RAR `.eti` whose tree buries a CRLF `SmartSteamEmu.ini` with a stub `PersonaName` line under `engine/bin/win64/steam_settings/`, plus a stub `account_name.txt` and `language.txt` under `profiles/local/`. A peer installs `css` (with `--unrar`), then sends `play css` with a username and language, then `play css` again. | After install the marker `games/css/launch_settings_applied` is absent and the stub files are intact under `local/`. The first `play` returns `already_applied=false` with `account_name_written`, `language_written`, and `persona_name_written` all true; the deep `SmartSteamEmu.ini` `PersonaName` value becomes the username with its `\r\n` ending and sibling lines preserved, `account_name.txt` becomes the username, `language.txt` becomes the passed language, and the marker now exists. A second `play` returns `already_applied=true`, rewrites nothing, and leaves the files untouched even if their values were reset externally. |
| S39 | Streamed install without keeping archive payload | Empty client connects to `fixture-bravo`, then sends `stream-install cnctw`. The source has real RAR `.eti` payload entries under `bin/` and `data/`; the receiver uses the container-bundled `unrar` stream provider. | Client emits `download-begin`, streamed `download-chunk-finished`, `download-finished`, and `install-finished` (the install-start transition is observable via `active-operations-changed`; there is no separate `install-begin` event). Local `cnctw` is `downloaded=false`, `installed=true`, `availability=LocalOnly`; root `version.ini` and `.eti` are absent; `local/bin/cnctw-payload.bin` and `local/data/cnctw-assets.dat` match `unrar p` output by SHA-256; the source reports no active outbound transfer for `cnctw` after completion. |
| S40 | Streamed install receiver is not a peer source | After S39, a third peer connects only to the streamed-install receiver. | The third peer may see the receiver's local-only summary in peer snapshots, but `list-games` remote aggregation does not expose `cnctw` as downloadable, `peer_count` remains zero/absent, and attempting `download cnctw` fails with no local files created. |
| S41 | Solid archive streamed install | Empty client connects to a peer serving `fixture-solid/cnctw`, whose `.eti` is a real solid RAR archive. The receiver uses the container-bundled `unrar` stream provider. | The fixture is verified as solid with `unrar lt`; streamed install finishes with `downloaded=false`, `installed=true`, `availability=LocalOnly`; root archive and `version.ini` are absent; streamed byte count equals the extracted solid entries; local payload SHA-256 hashes match `unrar p` output. |
| S42 | Streamed install whole-stream retry | Empty client connects to two peers serving the same catalog-version `cnctw`: one broken source whose `--unrar` path is missing, followed by one good source. | The broken source sorts before the good source in retry order, contributes zero chunks, and the good source completes a fresh whole-stream attempt. The final state is local-only installed, no root archive/sentinel, no `.local.installing`, byte count matches the extracted entries, and payload hashes match the good source. |
| S43 | Already-installed streamed install rejection | A client first stream-installs `cnctw`, then attempts `stream-install cnctw` again. | The second request emits `download-failed`, does not emit a new success event, leaves the existing local-only install intact, and clears active operations. |
| S44 | Corrupt archive streamed install rollback | A source advertises catalog-version `cnctw`, but its root `.eti` is replaced with invalid bytes before the client requests `stream-install cnctw`. | The stream emits `download-failed`, does not emit download/install success, clears active operations, and leaves no `local/`, `.local.installing`, root archive, or root `version.ini` on the receiver. |
| S45 | Sender disconnect during streamed install | A source serves large catalog-version `alienswarm`; after the client receives the first streamed chunk, the source container is killed. | The operation reaches a terminal failure/peers-gone event, emits no download/install success, clears active operations, and rolls back local/staging state. |
| S46 | Receiver cancel during streamed install | A client starts streaming large catalog-version `alienswarm`, receives the first chunk, then sends `cancel-download alienswarm`. | The receiver cancels without emitting download/install success or a user-visible download failure, clears active operations, and rolls back local/staging state. |
| S47 | Multi-archive streamed install order | A source serves `fixture-multi/cnctw` with two root `.eti` archives named to require sorted processing. | Streamed chunk paths arrive in root archive sort order, both payloads install under `local/`, the receiver is local-only installed, and no root archives or sentinel are committed. |
| S48 | Call to Play replication and late join | Alice and Bob connect; Alice publishes a call, then Bob publishes an RSVP and chat message. Charlie joins afterward and handshakes with Alice. | Alice and Bob receive the live events, while Charlie reconstructs the same three-event history during handshake with no duplicate event IDs. |
| ID | Scenario | Setup | Expected result |
| --- | ------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| S1 | Startup scan | Start one peer with `fixture-alpha`. | Peer emits `local-peer-ready` and `local-library-changed`; catalog fixture games are `downloaded=true`, `installed=false`, `availability=Ready`. |
| S2 | Direct connect handshake | Start alpha and bravo, then connect each side to the other's authenticated peer endpoint. | Both peers record one remote peer, no self-peer entry appears, and each direction's raw `GameAvailability` plus `remote-library-view` carries the exact `ContentId` from that side's fixture manifest. |
| S3 | Remote aggregation | Empty client connects to alpha and bravo. | `list-games` shows remote-only games once; shared `ggoo` has `peer_count=2`, unique games have `peer_count=1`. |
| S4 | Single-source download, no install | Empty client connected to bravo downloads `bfbc2` with `install=false`. | The fixture manifest, raw `GameAvailability`, `remote-library-view`, and every verified `download-chunk-finished` agree on the exact `ContentId`; every chunk names bravo's authenticated `PeerId`. Download finishes with `downloaded=true`, `installed=false`; root files exist and `local/` does not. |
| S5 | Auto-install download | Empty client connected to bravo downloads `cnctw` with default install. | Download finishes, install begins and finishes, and local `cnctw` is `downloaded=true`, `installed=true` with `local/fixture-payload.txt`. |
| S6 | Manual install and uninstall | After S4, client sends `install bfbc2`, then `uninstall bfbc2`. | Install marks `bfbc2` installed and creates `local/`; uninstall removes `local/` while preserving downloaded root files. |
| S7 | Duplicate-source catalog download | Empty client connects to alpha and bravo, which both advertise the exact catalog-version `ggoo`, then downloads it. | The receiver uses its local catalog manifest as the sole descriptor/hash authority, completes exactly once with chunks from both eligible peers and no duplicate chunk, and the downloaded package matches the fixture bytes. |
| S8 | Catalog file-shape enforcement and failover | Two peers start with exact catalog-version `ggoo`; after their authenticated IDs are known, the lower-`PeerId` source's `.eti` is made oversized. A fresh second receiver then connects only to the oversized source. | Exact catalog-file admission rejects the oversized archive assigned to the first authenticated source, and only the honest source supplies a successful archive chunk; an exact `version.ini` may validly come from either peer. The successful attempt has no invalid-data warning for this admission/transport rejection. The oversized-only receiver clears verification, emits `download-failed` with reason `verified-catalog-sources-exhausted`, and publishes neither `version.ini` nor `local/`. |
| S9 | Known catalog game with no source | An empty client asks for catalog-known `cod6` while connected to no peers. | The command acknowledges queueing, then emits an attempt-keyed `download-failed` with reason `verified-catalog-sources-exhausted`, without `download-begin` or verification activity. The game never enters active operations and no game root, `version.ini`, or `local/` is created. |
| S10 | Shutdown liveness cleanup | Alpha and bravo are connected, then bravo shuts down. | Within the named 125-second liveness allowance, pinned-liveness failure removes bravo and Alpha converges to an exactly empty authenticated-peer set and remote-library view. The protocol has no explicit departure control message. |
| S11 | Same identity reconnect | Bravo shuts down; Alpha first converges to an exactly empty peer set and remote-library view through bounded liveness, then Bravo restarts with the same state dir and reconnects. The OS-assigned listener port may or may not differ. | Alpha has exactly one bravo peer entry reusing the same peer ID, not a duplicate identity, and sees Bravo's library again at the newly authenticated endpoint generation. |
| S12 | Transfer serving gates | A peer has a non-catalog, missing-sentinel, active-operation, or `local/` path request. | The serving peer declines the transfer request; covered by unit tests where timing is too small for a stable CLI race test. |
| S13 | Exact transferred-file equality | Repeat small and large downloads, then compare every transferred regular file against its source with SHA-256 manifests. | Source and receiver manifests match exactly for each transferred file; no extra or missing files appear in the downloaded game root. |
| S14 | Large multi-peer chunked download | A source advertises a synthetic catalog game whose `.eti` is a sparse file of `4 * CHUNK_SIZE` (four 128 MiB chunks). A second peer downloads it, then a third peer downloads it from both peers. | The third peer's downloaded files match the source by SHA-256; `download-chunk-finished` shows the `.eti` split across exactly both peers, all four chunks accounted for, and the per-peer byte totals balanced within one `CHUNK_SIZE` (a fair 2+2 split; a 3+1 imbalance would trip the check). |
| S15 | Exact-content source selection | Peer A has a stale `version.ini` and publishes no availability. Peer B has a valid but different fixture catalog and `ContentId`. Peer C matches the client's exact catalog content. The client connects to all three and downloads with `install=false`. | Raw views distinguish B's wrong `ContentId` from C's expected `ContentId`; the client's catalog-joined `list-games` reports `peer_count=1`. Every verified chunk carries the expected `ContentId` and C's authenticated `PeerId`; A and B contribute no verified bytes. |
| S16 | Catalog-version fanout with stale peers present | Peer A has a stale version of a game. Peers B and C both advertise the catalog version with matching manifests; the `.eti` is inflated to `2 * CHUNK_SIZE` so it can fan out. | The aggregated row counts only catalog-version ready peers. The `.eti` chunks split across exactly B and C; peer A is not listed as downloadable and contributes no manifest vote or file chunks. |
| S17 | Catalog-byte verification and source quarantine | Two peers start with exact catalog-version `cnc4`; after their authenticated IDs are known, the lower-`PeerId` source's `.eti` receives a same-length byte corruption. A fresh second receiver then connects only to the corrupt source. | The first receiver detects the BLAKE3 mismatch, quarantines the corrupt source for that content ID, emits exactly one invalid-source retry activity after selecting the honest alternate, and only the honest source supplies a successful archive chunk; an exact `version.ini` may validly come from either peer. The all-bad receiver emits no false retry warning, clears verification, emits `download-failed` with reason `verified-catalog-sources-exhausted`, and publishes neither `version.ini` nor `local/`. |
| S18 | Mid-download source drop with redundancy | Client confirms two authenticated peers advertise the exact catalog `ContentId`, orders them by authenticated `PeerId`, then downloads a sparse `16 * CHUNK_SIZE` archive. Once the lower-ID source has four active outbound streams, the harness confirms no terminal event has occurred and force-kills it. | The download survives the active source failure without an invalid-data warning: no `download-failed` occurs, every verified chunk names the exact `ContentId` and one of the two authenticated `PeerId`s, all bytes arrive, and the receiver matches the surviving source. The surviving peer must complete the final even-offset chunk originally assigned to the lower-ID peer, proving retry rather than merely completion of its own initial plan. |
| S19 | Mid-download sole-source drop | Client downloads a sparse `8 * CHUNK_SIZE` archive from one source. Once four outbound streams are positively active and no terminal event has occurred, the source is force-killed. | The interrupted transport emits exactly one attempt-keyed `download-failed` with reason `verified-catalog-sources-exhausted`, after verification activity clears, and no `download-finished`; no invalid-data retry warning appears for a transport loss, no committed target `version.ini` or ready row remains, and the active operation drains so a retry is possible. |
| S20 | Receiver write failure | Client downloads a large game into a constrained `/games` filesystem. | The attempt verifies received chunks, then emits exactly one `download-failed` with reason `operation-failed`; no committed `version.ini` is advertised, and active operation state clears so the peer can retry later. |
| S21 | Add-game propagation | Two connected peers are running; one peer gains a new catalog game root through a completed download or an external drop. | The other peer receives a library update without reconnecting, and `list-games` shows the new remote game under the existing peer. |
| S22 | Remove-game propagation | Two connected peers are running; one peer loses a previously advertised game root. | The other peer receives a library update without dropping the peer, and `list-games` no longer shows that remote game. |
| S23 | Version bump propagation | Two connected peers are running; one peer's ready game root starts with a stale `version.ini`, then changes to the catalog version. | The other peer receives a library update without reconnecting; the stale row is absent before the change, then the catalog-version game appears as downloadable. |
| S24 | Two clients pull from one source | Two empty clients connect to the same source and download the same large game concurrently. | Both downloads finish, both receivers match the source by diff or SHA-256, and the source remains responsive. |
| S25 | One client downloads two games concurrently | One client connected to a source issues two different `download` commands without waiting for the first to finish. | Both operations may run in parallel; both eventually finish, each game reaches the requested install state, and each transferred root matches its source. |
| S26 | Same-game duplicate download rejection | A client starts downloading a game, then issues a second `download` command for the same game while the first operation is active. | The second request is rejected deterministically as an operation-in-progress condition; the first download is not corrupted and still reaches its documented final state. |
| S27 | Self-connect rejection | A peer sends `connect` with its own peer ID and advertised listener address. | The CLI command fails cleanly before dialing, no self-peer entry is created, and the peer remains responsive. |
| S28 | Reconnect generation fencing | The same authenticated peer endpoint is committed again, creating a newer endpoint generation, while a stale removal token from the earlier generation remains outstanding. | The newer generation is strictly greater, the stale removal loses authority, and the current authenticated endpoint remains. This is covered by the deterministic unit test `reconnect_gets_new_generation_and_stale_removal_loses_authority`. |
| S29 | Empty-library peer participates | An observer and an empty peer share the ordinary network. The source starts only on a scenario-internal network; the empty peer is attached there and dials it directly, while the observer remains unable to authenticate the source. | The observer first sees exactly the empty peer with zero games. After that peer downloads `alienswarm`, the observer remains authenticated only to it and receives its exact `ContentId` with `peer_count=1`; the downloader's verified chunks name the isolated source's authenticated `PeerId`. This proves local republishing without transitive library relay. |
| S30 | 5+ peer mesh aggregation | Five peers advertise partially overlapping catalog games with a mix of unique and shared catalog-version games; a sixth client connects to all five. | The client shows one row per game ID, correct catalog-version ready-source `peer_count`, catalog `eti_game_version`, no duplicates, and no self entries. |
| S31 | Bootstrapped peer becomes source in same session | An empty client downloads exact catalog content from one authenticated source, verifies every chunk's `ContentId` and source `PeerId`, then the original source is killed and a fresh third peer connects only to the bootstrapped client. | The third peer's exact authenticated peer set is only the bootstrap, its remote view reports the exact content with `peer_count=1`, every verified chunk names the bootstrap's `PeerId`, and its files match the original source by diff or SHA-256. This proves downloaded files become servable without restart. |
| S32 | Reinstall after uninstall | A downloaded game is installed, uninstalled, then installed again without another download. | `local/` is recreated from preserved root files, no transfer events occur during reinstall, and the game returns to `installed=true`. |
| S33 | Install after external root mutation | A downloaded game root is externally mutated before `install` is issued. | The CLI fixture installer installs from the current root bytes. The resulting `local/fixture-payload.txt` must match the mutated archive bytes exactly. |
| S34 | Many-small-files game without `.eti` | A catalog game root contains `version.ini` plus many small regular files and no archive. | Download with `install=false` transfers every file, chunk events are coherent for small files, and source/receiver manifests match exactly. |
| S35 | Unknown game ID from remote peer | A remote peer's own catalog advertises a game ID and exact `ContentId` absent from the receiver's catalog. | The raw peer snapshot and `remote-library-view` retain the typed availability, while the receiver's catalog-joined `list-games` omits it. Download fails deterministically and creates no local files. |
| S36 | Exact-content singleton beats stale majority | Five peers contain one game; one peer matches the client's catalog `ContentId` and four have stale versions that publish no transferable availability. | Raw snapshots omit the stale roots, `remote-library-view` reports the exact `ContentId` once, and catalog-joined `list-games` has `peer_count=1`. Every verified chunk names that content and the singleton peer's authenticated `PeerId`. |
| S37 | Single-source download throughput | A source peer advertises a Rust-published temporary catalog profile with one sparse `2 GiB` `.eti`; an empty client downloads it with `install=false`. | The exact `ContentId` agrees across the raw snapshot, remote view, and all 17 authenticated verified-chunk events. The attempt emits begin, verification, clear, and exactly one keyed `download-finished` with no failure. The only canonical root-relative paths are sixteen `bf1942.eti` chunks with exact 128 MiB lengths and offsets plus one eight-byte `version.ini` chunk at offset zero. Local state is downloaded, ready, not installed, and drained. The complete receiver root matches the source by SHA-256/diff. Throughput reports internally consistent byte, chunk, duration, MiB/s, and Mbit/s measurements, with `LANSPREAD_S37_MIN_MIB_PER_S` defaulting to the 100 MiB/s normal-LAN gate. |
| S38 | First-play launch-setting stamping | `fixture-persona/css` ships a real RAR `.eti` whose tree buries a CRLF `SmartSteamEmu.ini` with a stub `PersonaName` line under `engine/bin/win64/steam_settings/`, plus a stub `account_name.txt` and `language.txt` under `profiles/local/`. A peer installs `css` (with `--unrar`), then sends `play css` with a username and language, then `play css` again. | Before first play, the marker is absent and the installed bytes are exactly `stubaccount`, `english`, and the four-line CRLF INI with `PersonaName = stubplayer`. The first `play` returns all three write outcomes, stamps the requested values while preserving INI siblings/CRLF, and creates the marker. A second `play` returns `already_applied=true`, rewrites nothing, and leaves externally reset files untouched. |
| S39 | Streamed install without keeping archive payload | Source and empty client run alone on a scenario-internal network. The source has real RAR `.eti` payload entries under `bin/` and `data/`; the receiver uses the container-bundled `unrar` provider and sends `stream-install cnctw`. | One exact event window is `Active Downloading` → attempt-keyed `download-begin` → `verifying-downloaded-chunks` → two authoritative verified files (`bin` then `data`, exact path/size/offset, catalog `ContentId`, source `PeerId`/address) → activity clear → `Active Installing` → matching `download-finished` → `Active empty` → `install-finished`, with no failure. Throughput is exactly 3 MiB/two files. Final state is local-only installed with no root sentinel/archive; payload SHA-256 matches `unrar p`, and the source transfer drains. |
| S40 | Streamed install receiver is not a peer source | After a streamed install, the original source shuts down. An observer starts alone on a fresh internal network, proves an empty roster, then the receiver is attached and dialled at its internal address. | The observer roster becomes and remains exactly the receiver. Its authoritative raw snapshot, post-connect remote view, and catalog join omit local-only `cnctw`. An ordinary download acknowledges queueing, then emits attempt-keyed `download-failed` with reason `verified-catalog-sources-exhausted` and no begin or verification activity, success, active-operation snapshot containing `cnctw`, or game-root mutation. |
| S41 | Solid archive streamed install | Source and client run alone on a scenario-internal network using the solid catalog profile; the named source's `.eti` is verified as a real solid RAR before transfer. | The client roster/raw view carry the exact solid-profile `ContentId`, and every verified file is bound to the named source's authenticated `PeerId`. Streamed install finishes local-only with no root archive/sentinel; byte count equals the extracted entries and payload SHA-256 matches `unrar p`. |
| S42 | Streamed install integrity quarantine and retry | On an internal network, a lower-`PeerId` source serves a valid solid archive whose output mismatches the default catalog; a higher-`PeerId` source serves the exact default package. Both advertise the same exact catalog `ContentId`. | First install observes admission/drain edges on bad then good, emits one invalid-source retry activity only after rollback and alternate selection, and only good supplies authoritative verified files. After uninstall, the same client runtime retains both peers/raw availabilities; a second install observes good admission/drain, zero bad edges, and no invalid-source warning, proving runtime quarantine skip. Both keyed attempts finish with exact 3 MiB, good-source `ContentId`/`PeerId`, hashes, local-only state, and no staging/backup/sentinel/archive residue. |
| S43 | Already-installed streamed install rejection | A client first stream-installs `cnctw`, then attempts `stream-install cnctw` again. | The second attempt emits `download-failed` with reason `operation-failed` and no begin or verification activity, does not emit a new success event, leaves the existing local-only install intact, and clears active operations. |
| S44 | All-bad streamed integrity rollback | Named source and client run alone on an internal network. The source advertises exact default content but serves a verified-solid `cnctw` archive whose extracted output mismatches that catalog. | Exact roster/raw `ContentId` plus source admission/drain edges prove the named bad source was attempted. Catalog verification clears without falsely promising another source, then emits `download-failed` with reason `verified-catalog-sources-exhausted`; no download/install success occurs, active state drains, and no `local/`, staging, archive, or sentinel remains. |
| S45 | Sender disconnect during streamed install | Source and client run alone on an internal network for exact catalog `alienswarm`; after a verified chunk bound to that source `PeerId`/`ContentId`, the source is killed. | All observed chunks remain exact-source authoritative. The transport interruption clears verification and promptly emits `download-failed` with reason `verified-catalog-sources-exhausted`, without an invalid-data warning, before stale-peer liveness can elapse; no success occurs, active state drains, and local/staging state rolls back. |
| S46 | Receiver cancel during streamed install | Source and client run alone on an internal network for exact catalog `alienswarm`; after a verified chunk bound to that source `PeerId`/`ContentId`, the receiver sends `cancel-download`. | All observed chunks remain exact-source authoritative. Cancellation clears verification, drains active state, and rolls back local/staging state; graceful client shutdown then fences the completed JSONL slice, which contains no download/install success or user-visible download failure. |
| S47 | Multi-archive streamed install order | Source and client run alone on an internal network using `fixture-multi/cnctw`, with two root `.eti` archives named to require sorted processing. | The client roster/raw view carry the exact multi-profile `ContentId`, and every verified file is bound to the named source's authenticated `PeerId`. Paths arrive in root archive sort order, both payloads install under `local/`, final state is local-only installed, and no root archive/sentinel is committed. |
| S48 | Call to Play direct-author late join | Alice creates a call; Bob publishes RSVP/chat intents against its generated `CallId`. Alice and Bob remain connected while Charlie starts on a separate internal-only Docker network shared with Alice; Bob joins it only after Charlie's first pull. | Alice retains the exact Bob-inclusive view before and after Charlie's first pull, while Charlie's authenticated peer set is exactly Alice and its replacement contains only Alice's generated event ID. After the direct Bob pull it contains the exact three-event union once. Bob's departure converges to exactly Alice plus the creator event; Alice's departure then converges to an empty peer set and view. |
| S49 | Terminal Call to Play direct-author late join | Alice creates and later starts a call; Bob publishes ready/chat intents. Alice and Bob remain connected while Charlie first pulls Alice across an internal-only Docker network, then Bob joins that network for a direct pull. | Alice retains the exact four-event view throughout the first pull; Charlie is authenticated only to Alice and sees create/start without Bob-owned IDs. Pulling Bob produces the exact four-event terminal view once; creator departure removes the complete call after bounded liveness convergence while Charlie's authenticated peer set remains exactly Bob. |
## Version-Skew Contract
Use S15-S17 to pin down what happens when several peers have the same game ID
but only some match the local catalog version:
but only some match the receiver's exact catalog content:
- The receiver's catalog is authoritative. A remote root whose `version.ini`
does not match the catalog's expected version for that game ID is not
downloadable.
- `list-games` aggregates by game ID. The game appears once; `peer_count` counts
only ready peers with that ID and the catalog version.
- `list-games` joins raw remote availability against the local manifest. The
game appears once; `peer_count` counts only ready peers with the exact local
`ContentId`.
- The aggregated `eti_game_version` must be the catalog version.
- The descriptor set emitted to the download path, file-size validation, and
transfer planning are catalog-version-only. Stale peers must not supply
download descriptors, majority votes, or chunks.
- File paths, sizes, chunk boundaries, and BLAKE3 values come exclusively from
the receiver's bundled catalog. There is no remote descriptor preflight. Stale
or wrong-`ContentId` peers must not supply verified chunks.
- If exactly one peer has the catalog version, that peer is the only transfer
source. If several peers match the catalog version, validation and chunk
fanout happen among that catalog-version set only.
- Capture proof with the `list-games` row, `got-game-files` descriptors,
`download-chunk-finished` source addresses, and source/receiver SHA-256
manifests.
source. If several peers match, chunk fanout uses that set; byte mismatches
quarantine the exact source/content pair and retry elsewhere.
- Capture proof by matching the fixture manifest `ContentId` to raw
`GameAvailability`, `remote-library-view`, and every verified
`download-chunk-finished` event. Chunk proof uses authenticated `PeerId`; the
socket address is diagnostic only.
## Extended Failure And Mutation Contracts
@@ -88,8 +91,9 @@ GUI:
game and must not leave an active operation stuck.
- Source failure during a redundant download should retry failed chunks against
another validated source for the same catalog-version file.
- Live local library changes are observable by connected peers through library
deltas; reconnect is not required for add, remove, or version-bump cases.
- Live local library changes are observable through revision hints followed by
authoritative full snapshots; reconnect is not required for add, remove, or
version-bump cases.
- Same-game operations are single-flight. A duplicate download request while a
game is already active is rejected instead of starting another writer.
- Unknown remote game IDs are filtered by the receiver's current catalog and are
@@ -121,36 +125,187 @@ Use S38 to pin down how launcher settings are stamped into an installed game:
## Streamed Install Archive Contract
Use S39-S41 to pin down low-disk streamed installs:
Use S39-S47 to pin down low-disk streamed installs:
- The stream provider performs one archive metadata pass and one payload pass
per `.eti`, then frames entry boundaries for the receiver.
- Non-solid and solid archives both install into `local/` without committing a
root archive or root `version.ini`, so the receiver is installed but not a
downloadable source.
- Streamed install integrity is currently sender archive integrity: size and RAR
CRC32 must match the sender's archive metadata. The SHA-256 checks in the
scenarios prove the Docker/provider path matches the source fixture; they are
not catalog-owned trust anchors.
- RAR size/CRC32 checks are only an early sender-consistency check. The security
boundary is the receiver's catalog-owned extracted path set, sizes, and BLAKE3
file hashes. Scenario SHA-256 comparisons independently demonstrate that the
installed bytes match the intended fixture.
- S41 verifies the fixture is actually solid inside the source container, so
solid handling stays covered by the same Docker harness as the existing
streamed-install scenarios.
- S42 verifies retry/resume semantics: failed streamed attempts roll back their
staging directory and retry the whole stream from another validated peer.
There is no byte-offset resume contract.
- S42 verifies integrity quarantine and retry: a valid archive with extracted
output from the wrong catalog profile rolls back its staging directory, then
the receiver retries the whole stream from an honest matching source. There is
no byte-offset resume contract.
- S43-S47 cover the remaining streamed-install failure and archive-shape edges:
already-installed rejection, corrupt archive rollback, sender disconnect,
receiver cancel, and multi-archive root sorting.
already-installed rejection, all-bad catalog mismatch rollback, sender
disconnect, receiver cancel, and multi-archive root sorting.
## Run Log
### 2026-08-10 - Phase 5 Unfiltered Acceptance
- A fresh-image `LANSPREAD_S37_MIN_MIB_PER_S=100 just peer-cli-tests` run passed
every scenario from S1 through S49. S37 transferred the exact `2,147,483,656`
bytes in 17 verified chunks over `3.716s`, reporting `551.10 MiB/s` and
`4622.93 Mbit/s` against the active 100 MiB/s floor. These are Docker
acceptance measurements on this host and storage, not a representative
external-LAN performance claim. The run included the attempt-keyed
verification/retry/exhaustion traces, authenticated exact-content sources,
structured cancellation and rollback, streamed-install lifecycle, same-runtime
quarantine skip, direct-author Call to Play replacement, and non-vacuous
bounded peer-departure proofs.
- On the final implementation snapshot, `just test` passed all 708 workspace
tests (including 480 peer and 56 Tauri tests), `just clippy` passed,
`just frontend-test` passed 91/91, and `just build` passed the fixture catalog
checks plus the Deno/Vite and release-mode Tauri build. `just build` uses
fixture catalogs and is not the production corpus/bundle gate.
### 2026-08-10 - Phase 5 Typed Transfer Focused Acceptance
- This fresh-image command passed all fourteen scenarios:
```sh
LANSPREAD_S37_MIN_MIB_PER_S=100 just peer-cli-tests \
S8 S9 S17 S18 S19 S20 S37 S39 S40 S42 S43 S44 S45 S46
```
Their operation-local JSONL windows proved one canonical decimal attempt ID,
exact begin/verification/retry/clear/terminal milestone order, no status after
settlement, typed exhaustion versus local operation failure, no invalid-data
warning for transport loss, and silent user cancellation. S42 emitted the
invalid-source warning only for its first bad-to-good rollback; the same
runtime's quarantined-source retry emitted none. S37 transferred
`2,147,483,656` bytes in 17 verified chunks over `3.679s`, reporting
`556.69 MiB/s` and `4669.84 Mbit/s` against the active 100 MiB/s
Docker-on-this-host acceptance floor. This focused run is retained as targeted
evidence; the refreshed unfiltered S1-S49 result is recorded above.
### 2026-08-10 - Phase 4 v8 Unfiltered Acceptance
- A fresh-image `LANSPREAD_S37_MIN_MIB_PER_S=100 just peer-cli-tests` run passed
every scenario from S1 through S49. S37 transferred the exact `2,147,483,656`
bytes in 17 verified chunks over `6.999s`, reporting `292.61 MiB/s` and
`2454.61 Mbit/s` against the active 100 MiB/s floor. These are Docker
acceptance measurements on this host and storage, not an external LAN
performance claim. The same unfiltered run exercised the strengthened
exact-byte, lifecycle, topology, authenticated-source, quarantine, rollback,
and cancellation proofs in S38-S47, plus the direct-author Call to Play and
bounded-departure proofs in S48-S49.
### 2026-08-10 - Phase 4 v8 Focused Surface Acceptance
- A fresh-image `just peer-cli-tests S48` run passed the hardened direct-author
topology. Alice retained the exact Bob-inclusive view while Charlie's
authenticated peer set was exactly Alice and Charlie saw only Alice's creator
event. After Bob joined Charlie's network, Charlie pulled the exact union
directly; bounded liveness convergence then removed Bob's participant slice
and finally Alice's complete call.
- The unchanged-image command `just peer-cli-tests S12 S42 S48 S49` then passed
all four focused scenarios. S12 ran the current v8 transfer-admission unit
suite. S42 assigned the lower authenticated `PeerId` to the catalog-mismatched
source, quarantined it, and completed all `3,145,728` bytes from the exact
honest source. S49 reconstructed terminal creator and participant slices by
direct pulls and removed the complete call when the creator became stale,
while Charlie's authenticated peer set remained exactly Bob.
- A later fresh-image `just peer-cli-tests S18 S19 S31` run passed the hardened
source-failure cases. S18 observed four active outbound streams on the
lower-`PeerId` source before force-killing it; the survivor then supplied all
`2,147,483,648` archive bytes, including the final even-offset chunk
originally assigned to the killed peer, with no failure event and an exact
directory diff. S19 force-killed its sole source with four active streams and
reached `download-failed` with no ready row, sentinel, or active operation.
S31 proved exact `ContentId` and authenticated-source attribution on both the
original download and the bootstrapped peer's same-session re-serve before
matching the original fixture by diff.
- A subsequent fresh-image `just peer-cli-tests S29 S30 S31` run passed the
isolated bootstrap topology. S29 kept its source on an internal network and
attached only the empty peer; the observer remained authenticated exactly to
that formerly-empty peer before and after its download, then saw its exact
`alienswarm` `ContentId` with `peer_count=1`. S30 retained the expected six
aggregate game rows and per-content source counts across five peers. S31
proved an exact bootstrap-only peer set and `peer_count=1`, with each chunk on
the second hop attributed to that bootstrap before the directory diff matched.
- With `LANSPREAD_S37_MIN_MIB_PER_S=100`, the existing frozen image then passed
`python3 crates/lanspread-peer-cli/scripts/run_extended_scenarios.py S37`. The
exact-content single-source download transferred `2,147,483,656` bytes in 17
verified chunks over `10.138s`, reporting `202.02 MiB/s` and `1694.64 Mbit/s`.
All events carried the catalog `ContentId` and authenticated source `PeerId`;
their canonical root-relative paths comprised sixteen exact `bf1942.eti`
offsets plus `version.ini`, and the complete receiver directory matched the
source by SHA-256/diff. The configured 100 MiB/s floor was active.
- The same frozen image then passed
`python3 crates/lanspread-peer-cli/scripts/run_extended_scenarios.py S40 S45`.
S40 shut down the original source before starting the observer; the observer
authenticated exactly the local-only receiver, whose raw snapshot and
post-connect remote view both omitted `cnctw`, then observed the queued
ordinary download fail asynchronously without a game-root mutation. S45 killed
its sender after the first verified `alienswarm` stream chunk and observed
prompt `download-failed`, no success, drained active state, and complete
local/staging rollback before stale-peer liveness could elapse.
- The frozen image then passed the Python scenario runner for
`S38 S39 S40 S41 S42 S44 S45 S46 S47`. S38 proved the exact account, language,
and CRLF INI stub bytes before first play. S39 proved the complete ordered
streamed-install lifecycle, including both exact verified chunks (`3,145,728`
bytes total) from the isolated named source. S40 proved an isolated
empty-to-receiver topology and an asynchronous no-source failure with no
active-operation event or local mutation. S41 streamed the named solid source
and reproduced both expected hashes over 118 bytes. On S42's first install,
the mismatched and honest sources each emitted exactly two admission/drain
edges; after uninstall, the same receiver runtime emitted zero further edges
for the quarantined source and exactly two for the honest source while
reproducing the exact `3,145,728` bytes and hashes. S44 proved the sole bad
source was admitted and drained before rollback. S45 bound its first verified
chunk and prompt sender-loss failure to the exact authenticated source and
`ContentId`. S46 used a strict graceful event-loop drain to prove receiver
cancellation emitted no terminal success or failure. S47 bound the sorted
multi-archive install to its isolated named source.
- This was a focused post-cutover acceptance run, not a new unfiltered S1-S49
run. The full run below predates the final v8 Call to Play harness and compact
catalog-index cutovers and is retained only as historical baseline evidence.
### 2026-08-10 - Earlier Catalog Authority S1-S49 Baseline
- Built a fresh `lanspread-peer-cli:dev` image after the streamed-install
durability changes. The focused acceptance command
`LANSPREAD_S37_MIN_MIB_PER_S=100 just peer-cli-tests S8 S17 S37 S42 S44`
passed all five scenarios. S8 and S17 proved ordinary-download failover and
all-bad rollback for oversized and same-length-corrupt catalog content. S42
and S44 proved streamed-install quarantine/retry and all-bad rollback for a
valid archive whose extracted output mismatched the local catalog authority.
- The exact unfiltered command
`LANSPREAD_S37_MIN_MIB_PER_S=100 just peer-cli-tests` then passed S1-S49. This
includes the source-only unknown-game profile in S35, the solid profile in
S41, the multi-archive profile in S47, and the runtime-published temporary
profiles used by the large-file scenarios. These catalogs and manifests are
generated by the Rust fixture publisher; the peer does not derive authority
from runtime package contents.
- Fresh post-catalog-hash S37 evidence from the unfiltered run: a `2.00 GiB`
single-source download completed in `3.651s` at `560.93 MiB/s`
(`4705.43 Mbit/s`) and emitted exactly 17 verified chunks: sixteen 128 MiB
archive chunks plus `version.ini`. Environment: host `pfs-arch`, Linux
`7.1.6-arch1-1` x86_64, Docker network `lanspread`, dynamic profile
`dynamic-s37`, storage path `.lanspread-peer-cli/extended-scenarios` on
`/dev/dm-2` (`btrfs`), date `2026-08-10`. The 100 MiB/s normal-LAN acceptance
floor was active.
- The repository still intentionally contains no fabricated 186-game production
manifest corpus. The production bundle gate therefore remains fail-closed
until the publisher is run against the real package source.
### 2026-07-21 - Call to Play Transport (S48)
- Added JSONL commands to publish and inspect Call to Play events.
- Added JSONL commands to publish local Call to Play intents and inspect full
replacement views.
- S2 passed against the rebuilt image, preserving bidirectional library exchange
after the protocol version bump.
- S48 passed against the rebuilt image: create, RSVP, and chat propagated live,
then a late third peer received the same deduplicated history in handshake.
- The Phase 4 scenario now captures core-generated receipt IDs and proves that a
late third peer sees only Alice's author slice until it pulls Bob directly.
### 2026-06-21 - Test-Suite Integrity Audit And Hardening
@@ -178,19 +333,19 @@ Use S39-S41 to pin down low-disk streamed installs:
would now exceed one chunk); asserts an exact 2+2 split and full byte total.
- S16: inflated `.eti` to `2 * CHUNK_SIZE` so it fans out across both
catalog-version peers (the stock 120 MiB fixture is a single chunk).
- S19: force-kill right after `download-begin` on a multi-chunk file, accept
`download-failed`/`download-peers-gone`, assert no `download-finished` (the
old graceful shutdown could let a single-chunk transfer finish first).
- S19: force-kill right after `download-begin` on a multi-chunk file, require
the typed `download-failed` source-exhaustion terminal, assert no
`download-finished` (the old graceful shutdown could let a single-chunk
transfer finish first).
- S26: large sparse source so the first op is reliably still active, and
asserts the active `operation == "Downloading"` (no scenario checked it).
- S37: validates the throughput rate fields (positive, self-consistent
`mbit_per_s/mib_per_s == 8.388608`, `mib_per_s == bytes/duration`), not just
the byte count.
- S35: asserts the source actually advertises `mystery-game` before checking
it is filtered (distinguishes "filtered" from "never sent").
- S15: cross-checks each peer's raw advertised `eti_version` via list-peers
(the list-games `eti_game_version` is synthesized from the local catalog and
can only ever equal the catalog value).
- S35: asserts the source actually advertises `cod2` with its typed
`ContentId` before checking the receiver's local catalog filters it.
- S15: cross-checks raw typed availability for the wrong and expected
`ContentId` values; the catalog-joined list counts only the expected one.
- S2: polls for library convergence and verifies the bidirectional exchange
(bravo sees alpha's 3 games, not just alpha seeing bravo's 4).
- S11: dropped the "listener address must change" assertion (it tested the OS
@@ -200,17 +355,23 @@ Use S39-S41 to pin down low-disk streamed installs:
- S24/S25: assert the requested `install=false` final state.
- S34: assert exactly 21 coherent chunks (20 files + version.ini), 21 distinct
paths, no duplicates, instead of a `>= 21` floor.
- S27: added the `handshake::tests::inbound_hello_from_self_is_ignored` unit
test for the protocol-level self guard; the CLI scenario only exercises the
CLI string-compare guard, which short-circuits before any network call.
- Historical S27 note: protocol v7 added the
`handshake::tests::inbound_hello_from_self_is_ignored` test for its Hello
self guard. That test and handshake shape were removed by v8; the current
CLI scenario independently proves typed self-connect rejection and this old
test name is not current acceptance evidence.
- Harness: `find_fixture_game` now iterates `sorted(...)`, so the ambiguous
`cnctw` (bravo/multi/solid) resolves deterministically to `fixture-bravo`.
- Accepted as-is (reviewed, deliberately not changed): S20 (disk-full via chunk
`write_all` is equivalent coverage), S21 (inotify across the bind mount is
inherent to the harness), S30 (dup-row/self-peer checks are cheap defensive
guards), S32/S39/S44 absence checks (cheap regression guards against
committing a root sentinel), S42 IP-order precondition (deterministic by
container start order), S45 (the spec already names both terminal events).
guards), and S32/S39/S44 absence checks (cheap regression guards against
committing a root sentinel). S45 remained unchanged at this historical
checkpoint; current acceptance requires the prompt transport `download-failed`
rather than a later stale-peer event. S42 now persists two honest installation
identities first, assigns the mismatching profile to the lower decoded
`PeerId`, and proves that only the higher-ID honest source emits verified
chunks after retry/quarantine.
- Live runs against the rebuilt `lanspread-peer-cli:dev` image: baseline S1-S47
passed; post-fix S1-S47 passed. Post-fix evidence: S14
`{268435456, 268435456}` (balanced 2+2); S16 `.eti` split across B and C
@@ -251,9 +412,8 @@ Use S39-S41 to pin down low-disk streamed installs:
- Gates before Docker:
`python3 -m py_compile crates/lanspread-peer-cli/scripts/run_extended_scenarios.py`
passed.
- Targeted rebuilt-image runner:
`python3 crates/lanspread-peer-cli/scripts/run_extended_scenarios.py S3 S8 S14 S15 S16 S17 S21 S22 S23 S24 S29 S30 S31 S34 S36 S37 S39 S40 S41 S42 S43 S44 S45 S46 S47 --build-image`
passed.
- The rebuilt-image Python runner passed S3, S8, S14-S17, S21-S24, S29-S31, S34,
S36-S37, and S39-S47 with `--build-image`.
- S38 standalone runner:
`python3 crates/lanspread-peer-cli/scripts/run_extended_scenarios.py S38`
passed, proving the real-RAR `css` fixture installs with the container
@@ -274,9 +434,8 @@ Use S39-S41 to pin down low-disk streamed installs:
- Gates before Docker: `just fmt` and
`python3 -m py_compile crates/lanspread-peer-cli/scripts/run_extended_scenarios.py`
passed.
- Runner:
`python3 crates/lanspread-peer-cli/scripts/run_extended_scenarios.py S43 S44 S45 S46 S47 --build-image`
passed against the rebuilt `lanspread-peer-cli:dev` image.
- The Python runner passed S43-S47 with `--build-image` against the rebuilt
`lanspread-peer-cli:dev` image.
- S43 stream-installed `cnctw`, retried `stream-install cnctw`, observed
`download-failed`, and verified the existing local-only install stayed intact.
- S44 replaced the source `cnctw.eti` with invalid bytes. The receiver emitted
@@ -364,7 +523,7 @@ Use S39-S41 to pin down low-disk streamed installs:
`games/<id>/launch_settings_applied` marker.
- `just test` passed the whole workspace, including the new
`lanspread_peer::launch_settings` unit tests and
`install::transaction::install_resets_launch_settings_marker`.
`install::transaction::tests::install_resets_launch_settings_marker`.
- S38 host run: built `crates/lanspread-peer-cli/fixtures/fixture-persona/css`
with a stored RAR `.eti` (verified by `unrar t`) burying a CRLF
`SmartSteamEmu.ini` plus stub `account_name.txt`/`language.txt`. A host peer
@@ -399,8 +558,11 @@ Use S39-S41 to pin down low-disk streamed installs:
### 2026-05-18 - Full Automated Docker Matrix Pass
- Historical pre-v8 record: this section describes the then-current image and
does not establish current typed-identity, exact-`ContentId`, or v8 admission
behavior. See the 2026-08-10 focused acceptance entry for current evidence.
- Runner: `python3 crates/lanspread-peer-cli/scripts/run_extended_scenarios.py`
passed S1-S36 against the current `lanspread-peer-cli:dev` image.
passed S1-S36 against the then-current `lanspread-peer-cli:dev` image.
- S1-S17 rerun highlights: startup, direct connect, aggregation, download,
install/uninstall, duplicate-source, ambiguous metadata, missing game,
shutdown cleanup, identity reconnect, serve gates, exact equality, large
@@ -416,6 +578,8 @@ Use S39-S41 to pin down low-disk streamed installs:
### 2026-05-18 - Extended Scenario Docker Pass
- Historical pre-v8 record: the scenario details below preserve the behavior
tested at that date and are not current v8 authority or admission evidence.
- Runner: `python3 crates/lanspread-peer-cli/scripts/run_extended_scenarios.py`
passed for S18-S36 after rebuilding `lanspread-peer-cli:dev` with
`just peer-cli-image`.
@@ -442,8 +606,9 @@ Use S39-S41 to pin down low-disk streamed installs:
- S27 self-connect rejection: connecting a peer to its own listener returned
`cannot connect peer to itself ...`; `list-peers` stayed empty and the peer
stayed responsive.
- S28 address-change invariant: `just test` passed and included
`peer_db::tests::address_update_preserves_peer_identity_and_library`.
- Historical S28 recorded the then-current address-change invariant; it does not
establish the current v8 proof. Current S28 uses
`peer_db::tests::reconnect_gets_new_generation_and_stale_removal_loses_authority`.
- S29 empty-library peer: an observer first saw the empty peer with zero games;
after that peer downloaded `alienswarm`, the downloaded root diffed cleanly
and the observer's peer snapshot for that same peer contained `alienswarm`.
@@ -461,16 +626,18 @@ Use S39-S41 to pin down low-disk streamed installs:
- S34 many-small-files transfer: a `bf1942` fixture with 20 small regular files
and no `.eti` downloaded with `install=false`; 21 file chunks were observed
including `version.ini`, and the receiver diffed cleanly against the source.
- S35 unknown game ID: a source advertised `mystery-game` via `--fixture`; the
receiver filtered it out of `list-games`, `download mystery-game` returned
`game mystery-game is not in the local catalog`, and no local files were
created.
- S36 latest singleton: with one peer on `20260501` and four peers on
`20250101`, the client reported `peer_count=5` and latest `20260501`; only the
singleton latest peer sent chunks and the final root diffed cleanly.
- S35 unknown game ID: a source advertised `cod2`; the receiver filtered it from
`list-games`, rejected the download, and created no local files.
- S36 latest singleton: four stale-version roots and one then-current root were
present; the client selected the singleton current-version source and
completed the download. This historical result does not establish the later
exact-`ContentId` and authenticated-source contract.
### 2026-05-18 - Full Matrix Manual Docker Pass
- Historical pre-v8 record: command names, protocol behavior, and unit coverage
below belong to that snapshot. They are not evidence that current v8 tests ran
in May; current v8 admission proof is recorded in the 2026-08-10 entry.
- Build/setup: `just peer-cli-image` passed. Local `just peer-cli-build` needed
`RUSTC_WRAPPER=` because the host `kache` wrapper failed with a read-only
filesystem error; `RUSTC_WRAPPER= just peer-cli-build` passed.
@@ -489,8 +656,9 @@ Use S39-S41 to pin down low-disk streamed installs:
bravo. `list-games` showed `ggoo peer_count=2`; `alienswarm`, `bf1942`,
`bfbc2`, `cnc4`, and `cnctw` each had `peer_count=1`.
- S4 single-source no-install: `full-empty-client` downloaded `bfbc2` from bravo
with `install=false`. Events included `got-game-files`, `download-begin`,
`download-finished`, and local `installed=false`. Host verification:
with `install=false`. Events included `download-begin`, verified chunk
completions, `download-finished`, and local `installed=false`. Host
verification:
`diff -r crates/lanspread-peer-cli/fixtures/fixture-bravo/bfbc2 .lanspread-peer-cli/full-empty-client/games/bfbc2`
passed and `local/` was absent.
- S5 auto-install: `full-empty-client` downloaded `cnctw` with default install.
@@ -521,11 +689,9 @@ Use S39-S41 to pin down low-disk streamed installs:
- S12 transfer serving gates: this remains covered by unit tests because the CLI
cannot stably race raw transfer requests against non-catalog, missing
sentinel, active-operation, and `local/` path states.
`RUSTC_WRAPPER= just test` passed, including
`local_download_available_gates_on_catalog_operation_and_sentinel`,
`get_game_response_respects_serve_gates`,
`file_transfer_dispatch_respects_serve_gates`, and
`local_relative_paths_are_never_transferable`.
`RUSTC_WRAPPER= just test` passed its then-current serve-gate coverage; this
historical entry intentionally does not attribute later v8 test names to that
run.
- S13 exact transferred-file equality: the S4 small transfer and S14 large
transfer both passed host `diff -r` against the original source game
directories, proving exact file equality beyond event flow.