samiandClaude Sonnet 5
0af4a5c4fc
Pointed the existing RPC client at a real veloxd instance (isolated
HOME/XDG_RUNTIME_DIR/XDG_DATA_HOME — never touched the real ~/Downloads),
added a real download.add against tools/testserver, and watched it render
live end to end with no GUI code changes:
- handshake, subscribe, category.list/queue.list all match what DAEMON
reported
- the full event.task.state sequence and batched event.task.progress
both applied correctly by DownloadTableModel
- the written file's SHA-256 matches the server's reference
Filed gui/docs/daemon-requests-m1.md: TaskSummary.sizeBytes is never
populated by this daemon build, even in download.get after the task
completes with the exact byte count already on disk. Not a GUI bug —
ProgressDelegate and the model already do the documented right thing
when size is unknown (fall back to plain text, no bar) — but it means
every task renders without a percentage against the real daemon today.
mockd always supplies sizeBytes so this doesn't block current GUI work;
flagging before the M1 GUI<->daemon integration pass.
mockd stays the primary harness for the unhappy paths
(--slow/--flaky/--drop-connection) that a real daemon won't misbehave on
command for.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_016Ne28kx4VreeBWZv82Nksd
2.2 KiB
GUI → DAEMON requests (M1)
Filed by lane GUI, from independent verification of velox-gui against a real veloxd
(isolated HOME/XDG_RUNTIME_DIR/XDG_DATA_HOME, real tools/testserver transfer, GUI's
existing RPC client and model — no code changed for this check). Handshake, subscribe,
category.list/queue.list, the full event.task.state sequence, and batched
event.task.progress all match what DAEMON already reported. One gap, below.
TaskSummary.sizeBytes is never populated, even after complete
Repro:
download.add {"url": "http://127.0.0.1:<testserver>/throttled/file/8M", "segments": 4}
# ... wait for state: complete ...
download.get {"taskId": "<id>"}
Result's summary has no sizeBytes key at all (not null — absent) even once
downloadedBytes is 8388608 and state is complete. Same in the download.list item
and in every event.task.state / event.task.progress frame along the way.
This isn't a probe-order artifact on my end — I called download.add directly without a
prior download.probe, but the daemon has the size by the time the transfer finishes (it
wrote exactly 8388608 bytes) and download.get is documented as backing the progress
dialog with full detail, so the gap persists past the point where the daemon unambiguously
knows the answer.
Effect on the GUI: TaskSummary.sizeBytes is what DownloadTableModel uses for both
the Size column and the Status column's percentage — with it absent, Size renders — and
Status falls back to plain text ("Downloading" / "Complete") instead of the progress bar
with a percentage, for the entire life of every task. This isn't a rendering bug on this
end: ProgressDelegate and the model both do the documented right thing when size is
unknown (docs/03-gui-spec.md's screenshot shows a bar with a percentage — that needs a
byte count from somewhere). Screenshots from this run are attached to the session if useful
as a reference for what "no size" currently looks like end to end.
Not urgent — mockd always supplies sizeBytes, so this doesn't block M1 GUI work — but
worth knowing before the M1 GUI↔real-daemon integration pass, since the percentage bar is
the headline visual of the main table.