Files
lanspread/crates/lanspread-peer-cli
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.
2026-06-20 19:54:53 +02:00
..

lanspread-peer-cli

Scriptable peer harness for automated LAN-spread tests. The binary starts the core peer runtime without the Tauri GUI, reads one JSON command per stdin line, and writes JSONL events, results, and errors to stdout.

Running

just peer-cli-build
just peer-cli-image
just peer-cli-run alpha

Useful flags:

  • --games-dir PATH stores local archives and installs.
  • --state-dir PATH stores the generated peer identity.
  • --fixture GAME_ID seeds a tiny archive that the fixture unpacker can install.

Fixture Game Directories

fixtures/fixture-alpha, fixtures/fixture-bravo, and fixtures/fixture-charlie are ready-to-use game directories for local CLI smoke tests. Point --games-dir at one of them to start a peer with several catalog-backed fake games. Each game includes version.ini and a real RAR archive renamed to .eti; fixture-alpha and fixture-bravo share ggoo, while fixture-bravo and fixture-charlie share cnc4.

Commands

Every command is a JSON object with cmd or command; id is optional and is echoed back on the result or error line.

{"id":"s1","cmd":"status"}
{"id":"p1","cmd":"wait-peers","count":1,"timeout_ms":5000}
{"id":"c1","cmd":"connect","addr":"127.0.0.1:34567"}
{"id":"g1","cmd":"list-games"}
{"id":"d1","cmd":"download","game_id":"fixture-one","install":true}
{"id":"i1","cmd":"install","game_id":"fixture-one"}
{"id":"u1","cmd":"uninstall","game_id":"fixture-one"}
{"id":"q1","cmd":"shutdown"}

The status result includes receiver-side active_operations and sender-side active_outbound_transfers counts by game ID, which the scenario runner uses to verify transfer lifecycle cleanup.