LeyckerS/moondownloader

Follow-up to #174, which landed its minimal half in #176: web/-only pull requests now get a syntax check (node --check web/app.js). That catches parse errors and nothing else. render_gui.py already exists as a real GUI check — headless-Chromium screenshots that fail on JS runtime errors, element overflow, horizontal scroll, or missing rows. Wired into the same workflow it would gate the class of breakage the syntax check cannot see: code that parses and then breaks the page. What #174 established and what it did not: node --check was verified on the runner. render_gui.py inside a GitHub Actions runner was not — locally it needs pip install -r requirements.txt plus playwright install chromium, and #174 estimated ~1–2 minutes of job time. Whether it runs headless in CI at all, and what it actually costs, is the open question — so this is a problem statement, not a recipe. First step for whoever takes it: get render_gui.py to produce its screenshots in a runner on a scratch branch

Found while re-reviewing #154's counting paths. It exists on main independent of that PR, in both front-ends, so it gets its own issue per the usual scope rule. The accounting A run finishes only when every link is counted. In the CLI: mark_done() bumps n_done and sets all_done once n_done >= len(urls) (moon_cli.py:95-98); each browser_worker exits only on all_done.is_set() and q.empty() (moon_cli.py:183); run() gathers those workers (moon_cli.py:292). The engine is the same shape: mark_done at moon_engine.py:355-358, the worker's exit check at moon_engine.py:216. The dropped path A stall-killed download is re-queued for re-extraction with the same record (moon_cli.py:163-167; engine equivalent in _do_dl), and on pickup the entry is flagged is_re = rec.stall_kills > 0 (moon_cli.py:196, moon_engine.py:231). If that re-extraction then fails: the retry branch excludes it — not is_re at moon_cli.py:260 and moon_engine.py:316; the fail branch excludes it too — not is_re at moon_cli.py:

Both workflows filter by path, and web/ matches neither: .github/workflows/lint.yml triggers on **.py, requirements.txt, constraints.txt, ruff.toml, pytest.ini, .github/dependabot.yml, and itself (lint.yml:3-22). .github/workflows/docs-cli-check.yml triggers on **.md, **.py, and itself. So a pull request touching only web/app.js, web/index.html or web/styles.css arrives with an empty check list: no byte-compile, no lint, nothing. A missing brace in app.js would merge green — there is no green to withhold. #173, the current first-timer issue, even has to warn its taker that "no checks" is normal. The gap is asymmetric with the rest of the repository: #164/#165 established the principle that every file controlling behaviour triggers CI, and the GUI — a third of what users touch — is the one part left out entirely. The minimal gate, verified GitHub's ubuntu-latest runners ship Node.js, and node --check web/app.js parses the file without executing it — verified against current ma

On a run where 46 of 58 files failed, the GUI's headline card read: COMPLETED 58 / 58 [████████████████████ full green bar] and the pipeline said finished. The card immediately beside it, at a third of the size, read 12 ok · 46 failed. A user glancing at the top of the window sees a completed run. The run was 79% failure. Cause The card is fed by dl_done / dl_total, and _dl_done is incremented on every terminal outcome, not just success — moon_engine.py lines 166, 178 and 194 cover the already-exists, ok and failure paths alike. It is an accurate count of files the engine has finished dealing with; it is displayed under a label that promises something else. The DOWNLOAD 58 / 58 bar in the pipeline section has the same source and the same problem: it fills to 100% in success green regardless of how many of those files exist on disk. The data needed to render this correctly is already in the same snapshot — ok and fail are right ther

grep -n "snapshot\|stage\|url_done\|extract_done" moon_cli.py returns nothing. The CLI keeps its own bytes_acc, ok_count, dls_active, t0 and lock, and computes its own speed in progress_loop, duplicating what Engine.snapshot() already produces for the GUI. This is the same shape as the problem #41 fixed for download_file, Telemetry and ProxyPool — one behaviour, two copies, free to drift. They already have. The drift, observed on a real run A 5-link datanodes batch spent its first 24 seconds extracting. The CLI printed twelve consecutive identical lines: [00:02] 0/5 done | 0 active | 0 KB/s | 0.00 GB ... twelve times ... [00:26] 0/5 done | 1 active | 5.1 MB/s | 0.00 GB Forty-four percent of that run looked, from the terminal, like nothing was happening. The engine already knows better. snapshot() returns stage (extracting / downloading / done) and extract_done / extract_total, which is exactly what the GUI uses to say "Extracting [2/5]". The CLI has no concept of