conftest stubs download_file on moon_cli only — the engine keeps the real one, and nothing currently notices

[LeyckerS]

Found while verifying #157. Not currently causing a failure, which is exactly why it is worth writing down.

The problem

tests/conftest.py, lines 61–65:

for host in (moon_engine, moon_cli):
    monkeypatch.setattr(host, "extract_fuckingfast", fake_ff)
    monkeypatch.setattr(host, "extract_datanodes", fake_dn)
    monkeypatch.setattr(host, "close_ff_session", lambda: asyncio.sleep(0))
monkeypatch.setattr(moon_cli, "download_file", fake_download)

The extractors are stubbed on both front-ends. download_file is stubbed on moon_cli only — that last line sits outside the loop. moon_engine imports download_file directly from moon_download, so the engine tests hold the real function.

Why nothing has failed

run_engine in tests/test_no_chrome.py starts the engine with "mode": "links", which extracts and never downloads. Measured with a temporary probe:

PROBE ok/fail/dl_done/dl_total: 4 0 0 4
PROBE files in _tmp_out: []

Four successes, zero downloads, nothing on disk. The real download_file is present but never called, so the gap is invisible.

Why it matters anyway

The suite's whole promise is that it needs neither a browser nor a network — no-chrome runs on a bare CI box with only aiohttp, curl_cffi and pytest installed. That promise currently holds by accident on the engine side: change run_engine to "mode": "download", or add any engine test that downloads, and the suite starts making real HTTPS requests to dl.fuckingfast.co/...?fake from CI. It would be slow, flaky, and confusing to diagnose, and the person who trips it will not be looking at conftest.py.

It also has a live consequence worth knowing: result["ok"] from run_engine counts extracted links (moon_engine.py:270), not completed downloads. Anyone reading those tests would reasonably assume otherwise — I did.

The work

Move the download_file stub inside the loop so both front-ends get it, then confirm nothing depended on the asymmetry:

• pytest tests/ -q still green
• The engine tests still fail when the engine drops a URL. Demonstrate it — dropping the self._inc("_ok") at moon_engine.py:270 should turn test_engine_fuckingfast_only_launches_no_browser and test_engine_mixed_batch_launches_one_shared_browser red. That is how fix: remove the never-failing ok assertion in test_no_chrome.py (#155) #157 was verified and it takes a minute.

If moving it turns something red, say so on the issue rather than working around it — a stub that cannot be applied to the engine would be telling us something about the engine, and I would want to see that before it gets patched over.

Optional, and worth more than the fix: add a short comment above the loop saying that both front-ends must be stubbed and why, so the next edit does not re-introduce the split.

Small. No Windows machine needed.

[XEDAB]

I first went to moon_engine.py:270 and looked at it, it was a comment, I annotated self._inc("_ok") on lines 255 and 181 and it worked as expected (restored)