the COMPLETED counter and progress bar count failures as completions

[LeyckerS]

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 there, and the smaller card prints them.

What is needed

Decide what the headline number means and make the label and the bar agree with it. Say which you chose:

• Show successes: 12 / 58, with the bar filled to 12/58. Honest, and makes an in-progress run look slower than it is because a finished-but-failed file stops counting.
• Keep progress, colour the outcome: bar still reaches 100% because everything has been dealt with, but rendered in the failure colour, with 12 ok · 46 failed promoted so it cannot be missed at a glance.

The second is probably better — progress and outcome are genuinely two different things and the bar is the wrong place to encode outcome. But a full green bar on a run that mostly failed is not defensible in either reading.

Whatever is chosen, finished should not be the only word describing a run where most files did not arrive.

Acceptance criteria

• No run where files failed presents as unqualified success in the headline card or the pipeline bar
• Failure count is visible at the same glance as the completion count
• An all-successful run still looks exactly as it does today
• tests/test_snapshot.py is the place to pin whatever the metric ends up meaning — see test: Engine.snapshot() has no unit tests, and it is the contract every front-end depends on #57

Found by running the program: the run in question failed 46 files to a full disk and the interface reported it as finished.

[tomatotomata]

I traced the misleading progress state through moon_engine.py and the snapshot tests. The cleanest boundary seems to be keeping the completion counter as work processed, but deriving the headline status and bar presentation from the existing ok and fail counts so a failed run cannot look like an unqualified success.

I was thinking of a focused change in the snapshot/rendering path: preserve the all-successful appearance, promote the failure count whenever failures exist, and add cases for all-success, mixed, and all-failed runs in tests/test_snapshot.py. I would leave the downloader accounting itself unchanged. Is this issue still available, and does that direction fit what you had in mind?

[LeyckerS]

@tomatotomata — you asked a direct question two days ago and I left it sitting. That is on me, not you, and it is the one thing I have been telling everyone else not to do. Sorry.

Yes, it is still available, it is yours, and that direction is exactly right.

You landed on the option I thought was the better of the two without my saying so. The issue offered "show successes" or "keep progress, colour the outcome", and your reading — keep the completion counter as work processed, derive the headline status and the bar presentation from ok and fail — is the second, and for the right reason: progress and outcome are genuinely two different quantities and the bar is the wrong place to encode outcome. Counting only successes would make an in-flight run look stalled every time a file failed.

Three things worth having in mind, none of them changing your plan:

The data is already in the snapshot. ok, fail and kills are in metrics and the smaller card beside the headline already prints them. Nothing new needs computing — this is a presentation change, which is what makes it small.

Preserving the all-successful appearance is the constraint that matters. A run where everything worked should look exactly as it does today. If the change is visible on a clean run, it has gone too far.

Your test cases are the right three. All-success, mixed, all-failed. tests/test_snapshot.py exists now (it did not when the issue was written) and #57 is still open for broader contract coverage, so if you find yourself wanting a helper there, it will not collide.

One piece of context from after the issue was filed: the run that produced it failed 46 of 58 files to a full disk, and the interface reported finished with a full green bar. #116 covers the engine half — stopping the run instead of attempting every remaining link. Yours covers the half the user actually sees. They are independent; do not feel you need to touch #116's territory.

Take the time you need. And thank you for asking rather than guessing — that is what makes a change like this land in one round.