Implement progress reporting for in-flight commands - #115
Open
leandropineda wants to merge 2 commits into
Open
Conversation
progress_function was a stub returning 1, so a handler had no way to say a command was still running. A command that takes a while was therefore silent until it finished, leaving no way to tell slow progress apart from a stalled command. It now publishes a status update carrying "running", alongside the existing final result. No proto change: execution_status is already a free string. Reporting is opt-in, emitted only when a handler calls progress_function rather than automatically on dispatch. Some consumers act on the first status update they see, so a handler that does not opt in keeps reporting a single final status, exactly as before. progress_function keeps its signature, with both arguments now optional.
leandropineda
force-pushed
the
feat/command-progress-reporting
branch
from
September 2, 2026 20:08
ab3078a to
5effea6
Compare
The demo only had commands that answer instantly, so there was no way to try progress reporting or to see how a slow command behaves. Adds slow_success and slow_failure, both taking an optional seconds argument. Each reports once before starting, then periodically, then the real result - including the failure path with details, which the demo did not exercise at all before. They run on a thread rather than blocking the callback, since a handler that sleeps in place holds up everything else on that session.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
progress_functionhas been a stub since it was introduced:So a handler had no way to say a command was still running. A command that takes a while is silent until it finishes, leaving no way to tell slow progress apart from a stalled command.
What
CUSTOM_COMMAND_STATUS_RUNNING = "running"report_command_progress(), mirroringreport_command_resultbut with no return code — the command has not finished, so there is no outcome yetprogress_functionpublishes that, and no-ops when there is noexecution_idto correlate againstNo proto change:
execution_statusis already a free string, andstdout/stderrare already fields.Opt-in
Progress is emitted only when a handler calls
progress_function(), never automatically on dispatch. Some consumers act on the first status update they see, so a handler that does not opt in keeps publishing a single final status, exactly as before.progress_function(output, error)keeps its signature, with both arguments now optional, so existing callers are unaffected.Demo
The demo only had commands that answer instantly, so there was no way to try this. It now handles two custom commands, both taking an optional
secondsargument (default 20):slow_successslow_failureEach reports once before starting, then every 5 seconds, then the real result — including the failure path with details, which the demo did not exercise before. They run on a thread rather than blocking the callback, since a handler that sleeps in place holds up everything else on that session.
Screencast.2026-09-03.17.33.50.mp4
Tests
123 pass (119 existing + 4 new): progress publishes
runningwith no return code; a handler calling both emitsrunningthenfinishedunder one execution id; a handler that does not opt in emits only the final status; noexecution_idpublishes nothing.test_metrics.pyandtest_video.pyalready fail to collect onmainfor missing optional deps, unrelated to this change.