14b30fe2da4f0b4fe605ee23dee0235c601fc48e
18 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 ddidderr
|
2d53848e0c
|
test(peer-cli): harden S1-S47 scenario suite against vacuous and flaky checks
An adversarial audit of the headless peer-to-peer scenario suite
(crates/lanspread-peer-cli/scripts/run_extended_scenarios.py, driven by
`just peer-cli-tests`) found assertions that passed even when the behavior
they claim to test was not happening, plus timing races and doc-vs-code
divergences. A full baseline run (S1-S47) passed beforehand, confirming these
were test-quality gaps, not peer regressions; the baseline output itself
exposed the worst offenders -- e.g. S14 chunk totals {128 MiB, 1 MiB} (a
two-chunk file whose "balanced within one chunk" check can never fail) and
S16/S18 serving the whole ~120 MiB alienswarm.eti from a single source, so
fanout and retry were never exercised.
Test-correctness fixes (a broken behavior could previously pass green):
- S18: the "no download-failed" check was dead -- it reused a LineWaiter
already advanced past download-finished, so it scanned an empty tail.
Replaced with assert_no_event_since over the whole window. Switched to a
4*CHUNK_SIZE sparse archive so both peers get chunks; the test now proves the
download SURVIVES a mid-download source kill (every byte delivered, survivor
served part, no download-failed, clean diff). Retry-onto-survivor is the
mechanism but is not asserted: the kill/serve race against `docker rm -f`
cannot be forced, so asserting an exact split would be flaky.
- S7: the only check was a diff against byte-identical ggoo fixtures, so it was
source-agnostic. Added assertions that the download committed exactly once,
every chunk came from the validated two-peer set, both peers served, and no
chunk was fetched twice.
- S14: enlarged to 4*CHUNK_SIZE so the balance check can fail under a 3+1
imbalance; asserts an exact 2+2 split summing to the file size.
- S16: inflated the .eti to 2*CHUNK_SIZE so it fans out across both
catalog-version peers (the stock 120 MiB fixture is a single chunk).
- S37: validate the throughput rate fields (positive, self-consistent
mbit/mib == 8.388608, mib_per_s == bytes/duration), not just the byte count.
- S35: assert the source actually advertises the unknown game before checking
it is filtered, so "absent" means "filtered" and not "never sent".
- S15: cross-check each peer's raw advertised eti_version via list-peers; the
list-games eti_game_version is synthesized from the catalog and can only ever
equal the asserted value.
- S2: poll for library convergence and verify the bidirectional exchange
(bravo sees alpha's 3 games, not just alpha seeing bravo's 4).
- S12/S28: require the gating unit test to appear as "<name> ... ok" so an
#[ignore]d (un-run) test no longer satisfies the check.
- 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.
Flake fixes:
- S19: force-kill the sole source right after download-begin on a 4*CHUNK_SIZE
file and accept download-failed or download-peers-gone. The old graceful
shutdown on a single-chunk file could let the transfer finish first, turning
the expected failure into a download-finished. A chunk may complete before
the kill lands, but the full transfer cannot, so the failure is deterministic.
- S26: use a large sparse source so the first operation is reliably still
active when the duplicate request is issued (TOCTOU on active_operations);
also assert the active operation == "Downloading".
- S11: drop the "listener address must change" assertion -- it tested the OS
ephemeral-port allocator and could fail spuriously; keep the same-identity /
no-duplicate invariant.
Coverage and determinism:
- S27: add handshake::tests::inbound_hello_from_self_is_ignored for the
protocol-level self guard. The CLI scenario only exercises the CLI
string-compare guard, which short-circuits before any network call, so the
peer-crate guard had no test.
- find_fixture_game now iterates sorted(FIXTURES) so the ambiguous cnctw
(fixture-bravo/multi/solid) resolves deterministically to fixture-bravo.
Reviewed and deliberately left as-is (documented in the run log): S20, S21,
S30, S32/S39/S44 absence checks, S42 IP-order precondition, S45.
PEER_CLI_SCENARIOS.md rows S2, S11, S14, S16, S18, S19, S27 are updated to
match the harness, and a dated run-log entry records the audit, the fixes, the
accepted items, and the live-run evidence.
Test Plan:
- `just peer-cli-tests` (rebuilds the image, runs S1-S47 in Docker): baseline
passed; post-fix passed; a final run on the exact committed code passed
47/47. Evidence: S14 {268435456, 268435456} balanced 2+2; S16 .eti split
across B and C {134217728, 134217728}; S18 all 536870912 bytes delivered with
no download-failed; S19 deterministic download-failed; S37 ~874 MiB/s.
- `just test` (incl. inbound_hello_from_self_is_ignored), `just clippy`
(-D warnings, all-targets), and `just fmt` all pass.
Refs: PEER_CLI_SCENARIOS.md scenario matrix and 2026-06-21 run-log entry.
|
||
|
ddidderr
|
0b8e1e7f92
|
refactor: prune unconsumed peer lifecycle events
An emit-vs-listen audit of the event surface showed the GUI is state-as-source-of-truth: useGames renders the complete `games-list` snapshot (full library + active_operations) and reconstructs status from it, not from a stream of granular events. Several PeerEvents were emitted but had no consumer at all -- no frontend `listen()` and no peer-cli scenario assertion -- so they were pure dead weight that made the backend look event-driven when it no longer is. This prunes that dead surface in two parts. 1. Remove three PeerEvent variants with no consumer: InstallGameBegin, UninstallGameBegin, and RemoveDownloadedGameBegin. The operation-start transition is still observable via ActiveOperationsChanged (the snapshot already carries the Installing/Updating/Uninstalling/ RemovingDownload kind), so nothing is lost. This drops their emit sites in handlers.rs, the begin-event assertions in the peer's lifecycle unit tests (the asserted sequence is now ActiveOperationsChanged(kind) -> LocalLibraryChanged -> ActiveOperationsChanged([]) -> *Finished), the peer-cli JSONL mappings (install-begin/uninstall-begin/remove-download-begin) plus the now-orphaned install_operation_name helper and InstallOperation import, and the matching Tauri handler arms. 2. Drop Tauri webview emits that no frontend listener consumed: peer-local-ready, game-download-begin, game-download-pre, game-download-finished, game-uninstall-finished, and peer-connected/-disconnected/-discovered/-lost. The log lines and all real side effects are kept (handle_got_game_files still forwards PeerCommand::DownloadGameFiles). The orphaned emit_peer_addr_event and handle_download_finished helpers and the now-unused SocketAddr import are removed. peer-runtime-failed is kept pending a decision on surfacing runtime failures in the GUI. Why not re-wire instead: under state-as-source-of-truth, per-event UI state is exactly the pattern this project abandoned. Live progress already flows via game-download-progress, and the peer-cli's chunk, timing-trigger, and transition assertions read events that are retained (download-begin, download-chunk-finished, the *-finished/*-failed terminals), so test coverage is unchanged. Behavior change: none functional. The Tauri backend no longer emits events nothing listened to; the GUI is unchanged. The peer-cli no longer emits the three *-begin JSONL events. PeerEvent is a workspace-internal UI-reporting type, not a wire-protocol type, so there is no protocol or version impact and all consumers are updated in this commit. Docs: PEER_CLI_SCENARIOS.md S39 no longer lists install-begin (with a note that the start transition is visible via active-operations-changed), and a dated Run Log entry records the removal. The historical 2026-05-18 run-log note is left intact as a dated observation. Test Plan: - just test: pass (incl. peer lifecycle event-sequence tests). - just clippy: pass (-D warnings, all targets). - just frontend-test: pass (11/11, incl. streamed-install gating/labels). - just build: pass (release, no bundle). - Not run: the Docker S39-S47 matrix (run_extended_scenarios.py); those scenarios never asserted the removed *-begin events, so coverage is unaffected. just fmt's tombi step needs network and was skipped; no TOML changed. Refs: peer event-surface emit-vs-listen audit; no external consumers of the removed events. |
||
|
ddidderr
|
c00e6eae84
|
fix(peer): drain streamed install senders after completion
A streamed install sender kept the original frame sink alive outside the producer task. After the producer sent Complete, or an Error for a provider failure, the forwarding loop still had a live mpsc sender in scope and waited forever for another frame. Move the sink into the producer so the channel closes when the producer exits. That lets the QUIC writer close, the request task return, and the outbound TransferGuard drop after successful streamed installs and provider-side failures. The peer-cli harness now keeps the outbound-transfer map it passes into the peer runtime and exposes per-game counts in status. S39 asserts that the source has no active outbound transfer for cnctw after the streamed install finishes, which catches the sender-side lifecycle leak that receiver-only assertions missed. The peer-cli README and scenario table document that status field and expectation. Test Plan: - just fmt - just test - just clippy - git diff --check - git diff --cached --check - python3 crates/lanspread-peer-cli/scripts/run_extended_scenarios.py S39 S40 --build-image - python3 crates/lanspread-peer-cli/scripts/run_extended_scenarios.py S41 S42 S43 S44 S45 S46 S47 Refs: NEXT_STEPS.md streamed install lifecycle hardening |
||
|
ddidderr
|
66c7d5912b
|
fix(peer): harden streamed install lifecycle
Claude Fable 5's branch review found that receiver cancellation or a QUIC send failure could leave the sender-side archive producer blocked on the bounded frame channel. That kept the outbound transfer guard alive and could block later installs or updates of the same game. Route archive frames through a cancellable StreamInstallFrameSink instead of exposing the raw channel sender to providers. The QUIC forwarder now cancels and closes the receive side before awaiting the producer, so a blocked send wakes and the transfer guard can drop normally. Make PeerCommand::StreamInstallGame own its peer metadata preflight inside the peer core. The Tauri layer now sends the command directly, and the peer runtime fetches file details from catalog-version peers before running the existing majority validation and retry logic. This removes the UI-only pending streamed install set and gives PeerEvent::GotGameFiles one meaning again: continue a normal archive download. Tighten the receiver transaction edge cases too. Rollback removes a newly created empty game root, but preserves pre-existing roots. Once streamed staging has been promoted to local/, intent or launch-settings cleanup failures are logged for startup recovery instead of reporting a failed install for bytes that are already committed. Accept missing RAR CRC32 metadata for zero-byte files as CRC32 00000000 while still requiring CRC32 metadata for non-empty files. Update the peer README, scenario docs, and next-steps handoff so the documented ownership and remaining trust limitation match the implementation. Test Plan: - just fmt - just test - just frontend-test - just clippy - git diff --check - python3 -m py_compile \ crates/lanspread-peer-cli/scripts/run_extended_scenarios.py - python3 crates/lanspread-peer-cli/scripts/run_extended_scenarios.py \ S39 S40 S41 S42 S43 S44 S45 S46 S47 --build-image Refs: streamed-install review handoff from Claude Fable 5 |
||
|
ddidderr
|
47ef87748f
|
test(peer-cli): align scenarios with catalog versions
Remote aggregation now filters to catalog-version roots, but the checked-in peer-cli fixtures and skew scenarios still stamped synthetic future versions. That hid fixture rows in S3 and left scenario docs asserting latest-version behavior. Teach the harness the catalog versions for fixture game IDs, stamp generated fixtures with catalog versions by default, and update skew, mesh, propagation, and throughput scenarios to expect only catalog-version peers. Also wire S38 into the executable matrix so the documented first-play launch-setting scenario is covered by the same full run as S1-S47. This keeps stale peers as negative coverage: they are absent from list-games and cannot provide descriptors, votes, or chunks. The fixture version.ini updates are checked in so alpha, bravo, charlie, and persona roots advertise downloadable catalog games again. Test Plan: - python3 -m py_compile crates/lanspread-peer-cli/scripts/run_extended_scenarios.py - 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 - python3 crates/lanspread-peer-cli/scripts/run_extended_scenarios.py S38 - python3 crates/lanspread-peer-cli/scripts/run_extended_scenarios.py - git diff --check - git diff --cached --check Docs: PEER_CLI_SCENARIOS.md |
||
|
ddidderr
|
9288fda037
|
test(peer-cli): expand streamed install edge coverage
NEXT_STEPS item 6 called for the remaining streamed-install edge cases to be covered in the peer-cli matrix. Add S43-S47 for already-installed rejection, corrupt archive rollback, sender disconnect, receiver cancel, and sorted multi-archive streaming. The receiver-cancel scenario needs the harness to drive the same runtime path as the GUI, so `lanspread-peer-cli` now accepts a narrow `cancel-download` command that forwards to `PeerCommand::CancelDownload`. A parser test covers the new JSONL command shape. Add `fixture-multi/cnctw`, a tiny two-archive RAR fixture. S47 uses it to prove streamed installs process root `.eti` archives in sorted order and commit only extracted `local/` payloads, not the root archives or `version.ini` sentinel. Test Plan: - just fmt - python3 -m py_compile crates/lanspread-peer-cli/scripts/run_extended_scenarios.py - python3 crates/lanspread-peer-cli/scripts/run_extended_scenarios.py S43 S44 S45 S46 S47 --build-image - just test - just clippy - git diff --check - git diff --cached --check Refs: NEXT_STEPS.md item 6 |
||
|
ddidderr
|
88bfaeb04a
|
test(peer-cli): cover streamed retry fallback
NEXT_STEPS item 5 needs streamed installs to have an explicit retry policy. The handler already retries whole-stream attempts across the majority-validated peer set, so add S42 to prove that behavior with the Docker harness instead of leaving it implicit. S42 starts two catalog-version-matching `cnctw` sources. The first source sorts first in retry order but has `--unrar /missing-unrar`, so its stream attempt fails before sending chunks. The second source then completes a fresh whole-stream attempt. The scenario asserts local-only installed state, no root archive or sentinel, no `.local.installing` staging leftover, chunk events only from the good source, matching streamed byte count, and SHA-256 payload equality against the good source's `unrar p`. This pins the current policy: retry the entire stream from another validated peer, do not preserve partial files across attempts, and do not promise byte-offset resume. Test Plan: - python3 -m py_compile crates/lanspread-peer-cli/scripts/run_extended_scenarios.py - python3 crates/lanspread-peer-cli/scripts/run_extended_scenarios.py S42 - git diff --check - git diff --cached --check Refs: NEXT_STEPS.md item 5 |
||
|
ddidderr
|
bb7497c0ff
|
refactor(peer): name streamed integrity boundary
NEXT_STEPS item 4 needed the streamed-install integrity model to be a conscious decision. Keep the current runtime behavior, but name it as sender archive integrity: the receiver verifies streamed file size and RAR CRC32 from the sender's archive metadata before committing the install transaction. This protects against truncation, transport corruption, and stream provider bugs. It deliberately does not claim malicious-peer protection, because the sender controls both the streamed bytes and the RAR metadata. The docs now say that trusted content requires a future catalog schema with catalog-owned archive or extracted-file SHA-256 hashes. Test Plan: - just fmt - just test - just clippy - python3 crates/lanspread-peer-cli/scripts/run_extended_scenarios.py S41 --build-image - git diff --check - git diff --cached --check Refs: NEXT_STEPS.md item 4 |
||
|
ddidderr
|
0e970dcec7
|
test(peer-cli): cover solid streamed installs
NEXT_STEPS item 3 needed solid archive handling to be a deliberate contract instead of an incidental RAR header attribute. Add a tiny real solid RAR fixture and S41 to the extended peer-cli scenarios so the Docker harness proves this path end to end. The scenario verifies the source archive with container-bundled `unrar lt`, streams the install with the injected provider, and then asserts the receiver is installed local-only without a root archive or root `version.ini`. It also compares local payload SHA-256 hashes against `unrar p` output and checks the streamed byte count matches the extracted entries. This keeps the existing one metadata pass plus one sequential payload pass contract covered for solid archives. Test Plan: - just fmt - just test - python3 -m py_compile crates/lanspread-peer-cli/scripts/run_extended_scenarios.py - python3 crates/lanspread-peer-cli/scripts/run_extended_scenarios.py S41 --build-image - python3 crates/lanspread-peer-cli/scripts/run_extended_scenarios.py S41 - git diff --check - git diff --cached --check Refs: NEXT_STEPS.md item 3 |
||
|
ddidderr
|
373def6d44
|
feat(peer): prototype streamed installs
Add a streamed-install prototype that can receive archive-derived install bytes straight into local/ without first storing the peer-owned root archive payload. This is intended for low-disk clients that want to install a game but opt out of becoming a downloadable peer source for that game. The protocol gains a current-version-only StreamInstall request and framed StreamInstallFrame responses. The peer core owns the generic transport, transaction, path validation, size checks, CRC32 verification, and lifecycle state. The archive-specific work is hidden behind StreamInstallProvider so the prototype can use unrar while the final implementation can swap in a better provider without rewriting the peer command path. The receiver writes into .local.installing and only promotes to local/ after the full stream verifies. It deliberately does not write the root version.ini or archive files, so the settled local state is installed=true, downloaded=false, and availability=LocalOnly. That preserves the existing rule that local/ is not served to peers and makes streamed receivers non-sources by construction. The CLI is the only caller for now. It exposes stream-install and provides the prototype unrar implementation with unrar lt for entry metadata and unrar p for file bytes. This is simple and good enough to prove non-solid archive streaming, but it is not the production provider shape for solid archives because per-file unrar p would repeatedly decompress prefixes. The Tauri app explicitly passes stream_install_provider: None, so the GUI behavior stays unchanged until a real product path is designed. Document the production-readiness work in NEXT_STEPS.md. The main follow-up is to make the provider abstraction final-ish and replace the per-file CLI unrar provider with a one-pass archive provider, then wire a deliberate GUI low-disk mode, retry semantics, and broader failure scenarios. Test Plan: - just fmt - RUSTC_WRAPPER= CARGO_BUILD_RUSTC_WRAPPER= just test - python3 crates/lanspread-peer-cli/scripts/run_extended_scenarios.py \ S39 S40 --build-image - RUSTC_WRAPPER= CARGO_BUILD_RUSTC_WRAPPER= just clippy - git diff --check - git diff --cached --check Follow-up: NEXT_STEPS.md |
||
|
ddidderr
|
09709cc008
|
feat(peer): stamp launcher settings on first play, add PersonaName rewrite
Some games ship a SmartSteamEmu.ini somewhere under their installed
local/ tree with a `PersonaName = ...` line that must carry the player's
configured username. They also ship account_name.txt and language.txt
files that the launcher already overwrote with the username/language.
Previously that account_name.txt/language.txt overwrite happened inside
the install transaction, so it only applied to freshly (re)installed
games — games already installed by an older build never got fixed up,
and the SmartSteamEmu.ini PersonaName line was not handled at all.
This moves all per-user setting application out of install and into a
single one-shot step performed the first time a game is played, gated by
a new per-game marker `games/<id>/launch_settings_applied` under the
state dir. On first play we search the whole local/ tree and stamp:
- the username into the first account_name.txt,
- the language into the first language.txt,
- the username into the first SmartSteamEmu.ini PersonaName line,
preserving that line's existing line ending (\n or \r\n) and its
surrounding whitespace, leaving sibling lines untouched.
The marker only records that we *tried*: it is written unconditionally
after the first play, so a game with none of these files is still marked
done and never rescanned. Because already-installed games have no marker
yet, they are fixed up on their next play rather than only on reinstall.
To keep the marker honest across version changes, the install and update
transactions now clear it on success, so a freshly extracted local/ is
re-stamped on the next play.
Behavior changes from the user's perspective:
- The first time you press Play after this change, your username/
language are (re)applied to an existing install, including games you
installed before this feature existed.
- SmartSteamEmu.ini's PersonaName now reflects the launcher username.
Plumbing: account_name/language are removed from PeerCommand::InstallGame
/DownloadGameFiles[WithOptions] and the whole install handler chain, and
the Tauri pending_install_settings bookkeeping is gone — the launcher now
computes the values at play time in run_game and calls
lanspread_peer::apply_launch_settings_once. The headless harness gains a
`play` command exposing the same step for scripted testing.
Test Plan
- just test: new lanspread_peer::launch_settings unit tests cover the
PersonaName rewrite, \n/\r\n preservation, first-match search, the
unconditional marker, and the no-op-once-applied path; a transaction
test covers the install marker reset. Whole workspace is green.
- just clippy clean; the change adds no new clippy warnings (incl.
--tests).
- S38 (new in PEER_CLI_SCENARIOS.md): host run of lanspread-peer-cli
against the new fixture-persona/css RAR .eti (with --unrar) installs
css, then `play css` stamps the deeply-buried CRLF PersonaName line,
account_name.txt, and language.txt and creates the marker; a second
`play` is a no-op even after the values are reset externally.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
||
|
ddidderr
|
8a9f420a06
|
test(peer-cli): measure single-source download throughput
Add peer-cli accounting for download sessions so terminal download events report bytes, chunks, elapsed time, MiB/s, and Mbit/s. The extended scenario runner now has S37, a focused single-source download benchmark that creates a 2 GiB sparse bf1942 archive, downloads it from one peer with install disabled, and checks the destination archive size and reported byte count. This gives the QUIC performance work a repeatable measurement below the 5 GiB limit from the original request. The source file is sparse, so S37 is aimed at the app, QUIC, and destination-write path rather than raw source-disk reads; the existing correctness scenarios still cover normal game downloads. Baseline S37 before QUIC tuning: - 733.22 MiB/s - 6150.72 Mbit/s - 2.793s for 2.00 GiB plus version.ini - 65 reported chunks Test Plan: - just fmt - python3 crates/lanspread-peer-cli/scripts/run_extended_scenarios.py S37 --build-image Refs: local LAN download performance investigation on 2026-05-20. |
||
|
ddidderr
|
e078b12dcf
|
docs(peer-cli): record snapshot status matrix pass
Record the post-fix peer-cli validation run against the rebuilt Docker image. The run covered S1-S36 after the backend snapshot-ordering fix and frontend snapshot-status reducer cleanup, including auto-install, exact transfer, failure, propagation, concurrency, mutation, and latest-version scenarios. Test Plan: - git diff --check - just peer-cli-image - python3 crates/lanspread-peer-cli/scripts/run_extended_scenarios.py Refs: local install/download status snapshot cleanup |
||
|
ddidderr
|
a8edcd7450
|
test(peer-cli): cover full docker scenario matrix
Merge the S18-S36 scenario ideas into the official peer-cli scenario matrix and add a Docker-backed runner that now exercises S1-S36 with concrete file proofs. The runner creates temporary fixtures under .lanspread-peer-cli, drives JSONL peer containers, checks transferred roots with diff and SHA-256 manifests, and covers startup, discovery, transfer, failure, mutation, concurrency, mesh, lifecycle, and catalog edge cases. The scenarios exposed a few harness/runtime boundary gaps that would otherwise make the contract ambiguous. The peer CLI now rejects self-connects, rejects commands for game IDs outside the receiver catalog, filters unknown remote games from its command/event surface, and reports duplicate active same-game commands as operation-in-progress errors. The peer core also refuses non-catalog download commands before transfer, and PeerGameDB has a unit check that address changes preserve identity and library state. S12 and S28 remain unit-level invariants because the CLI cannot stably race raw serve-gate requests or rebind a live listener without restart. The runner treats those scenarios as covered by just test and checks the expected unit test names appear in the output. Test Plan: - just fmt - python3 -m py_compile crates/lanspread-peer-cli/scripts/run_extended_scenarios.py - RUSTC_WRAPPER= just test - RUSTC_WRAPPER= just clippy - RUSTC_WRAPPER= just peer-cli-build - just peer-cli-image - python3 crates/lanspread-peer-cli/scripts/run_extended_scenarios.py - git diff --check Refs: PEER_CLI_SCENARIOS.md S1-S36 |
||
|
ddidderr
|
8b3aefd2db
|
test(peer-cli): document full manual scenario pass
Record the May 18 manual Docker pass over PEER_CLI_SCENARIOS.md so the scenario matrix has current evidence for every row. The run log now covers the clean direct-connect and aggregation rerun, exact diff checks for downloaded files, custom renamed-RAR fixtures for conflict and version-skew cases, and the latest-only transfer behavior for S15-S17. S12 remains verified by unit tests instead of a CLI race because the raw serving gates are below the peer-cli command surface. The run log names the exact tests that cover the non-catalog, missing-sentinel, active-operation, and local-path serving gates. Test Plan: - just peer-cli-image - RUSTC_WRAPPER= just peer-cli-build - manual Docker peer-cli runs for S1-S17 using JSONL stdin commands - diff -r transferred game directories against source fixture directories - just fmt - RUSTC_WRAPPER= just test - RUSTC_WRAPPER= just clippy - git diff --check Refs: PEER_CLI_SCENARIOS.md |
||
|
ddidderr
|
41e9a0efc1
|
refactor(peer): split local library and operation UI events
Replace the `a9f9845` local-update dedup cache with explicit peer event semantics. Local scans now emit `LocalLibraryChanged` when the library changes, while operation mutations emit `ActiveOperationsChanged` from the mutation path. Tauri keeps joining those facts into the existing `games-list-updated` payload, so the frontend contract stays stable. This removes the cache/invalidation coupling between scan emission and operation state. The remaining forced local snapshot is explicit: accepted game directory changes can refresh the UI for an equivalent new path without sending a peer library delta. Operation guard cleanup and liveness cancellation now publish the same active operation snapshot as normal command-handler transitions. The peer CLI JSONL events follow the same split with `local-library-changed` and `active-operations-changed`. Test Plan: - `just fmt` - `CARGO_BUILD_RUSTC_WRAPPER= just test` - `CARGO_BUILD_RUSTC_WRAPPER= just clippy` - `git diff --check` Refs: CLEAN_CODE_PLAN_1.md |
||
|
ddidderr
|
274b9d2fd4
|
test(peer-cli): add large exact-transfer coverage
Add deeper peer CLI coverage for file-transfer integrity and multi-peer chunking. The alpha fixture now carries a real renamed RAR archive larger than 100 MB for alienswarm, which gives the chunk planner enough work to split a single game archive across multiple peers. Expose completed chunk source details as a peer event and have the CLI print that event as JSONL. This keeps transfer behavior in lanspread-peer while the CLI remains a harness that reports what the peer runtime did. The Tauri shell logs the event at debug level so the shared PeerEvent enum stays exhaustive. Document the new S13/S14 scenarios and record the manual run evidence, including SHA-256 manifests and the per-peer byte split for the large archive. Test Plan: - just fmt - just test - just peer-cli-build - just clippy - just peer-cli-image - unrar t -idq crates/lanspread-peer-cli/fixtures/fixture-alpha/alienswarm/alienswarm.eti - Manual peer CLI: bravo -> deep-small-client bfbc2 download with matching SHA-256 manifests - Manual peer CLI: alpha -> deep-stage-b alienswarm download with matching SHA-256 manifests - Manual peer CLI: alpha + deep-stage-b -> deep-stage-c alienswarm download with chunk events from both peers and matching SHA-256 manifests Refs: PEER_CLI_SCENARIOS.md S13 S14 |
||
|
ddidderr
|
9a677947ed
|
testing: peer CLI pre-defined peers |