[Lab] Verify triggered capture's live log on the Linux rig

Open
  • Is something wrong?
#810 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
32/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
rust, shell
Domain
cli, testing-qa

Research direction

Start with MatchCtrl::live_log_path and log_text, which decide where the trigger reads the match log, then read harvest_reads_the_stdout_buffer_when_there_is_no_qconsole for the stdout fallback. The work needs a live Linux lab match, so check tools/setup_rig.sh first. Done means watch-pov either fires on a Linux match or refuses with an error that names the expected path and suggests --log.

Written by the indexing model from the issue text.

Description

lab P3 rust-mcp

Context

watch-pov and bot_capture_pov_frame with on (#795) tail runs/<run>/qconsole.log, from MatchCtrl::live_log_path. QuakeSpasm on Windows writes it there because the lab launches the engine with its working directory set to the run directory.

The controller already treats that file as optional on other platforms: log_text falls back to the captured stdout buffer, and harvest_reads_the_stdout_buffer_when_there_is_no_qconsole exists for that case. If the Linux engine writes the log somewhere else, or not at all, the trigger tail fails with "no live match log", and the CLI's auto-discovery finds nothing.

Not verified: watch-pov has never run on the Linux rig, and tools/setup_rig.sh's own revision still awaits a live rig.

Proposed

Start a lab match on the Linux rig and run watch-pov. If the file is absent, tail the controller's stdout buffer in the MCP path, and make the CLI error name the expected path and suggest --log.

Acceptance

watch-pov fires on a Linux lab match, or refuses with a message naming where it expected the log.

Dominant language
Rust
Stars
4
Forks
0
Avg merge
30m
Merged PRs (30d)
130

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from saworbit/argus

All issues in saworbit/argus

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.