feat(mcp): wait option for compile, upload and task status - #25
Merged
Conversation
Every compile and upload previously forced the caller into a polling loop:
the tool returned a taskId immediately and the agent had to call
arduino_task_status repeatedly - the single biggest source of orchestration
overhead when driving the tools (a real hardware session rewrote the same
polling loop more than ten times).
arduino_compile and arduino_upload now accept wait:true plus
timeout_seconds (default 60, clamped 5-600). The dispatch keeps each
runner's completion promise (they were fired through setImmediate and
discarded), and waitForTask races it against the timeout:
- finished: the full terminal result in one call
- timeout: {taskId, status, progress, progressMessage, timed_out: true}
with a hint - deliberately NOT an error, so a long first build simply
gets re-waited via arduino_task_status {wait:true}, which now blocks on
in-flight tasks the same way.
Tasks also gain createdAt/startedAt/finishedAt timestamps, and pruneTasks
clears the promise map and treats 'cancelled' as evictable.
Verified on the ESP32-S3: 5s-timeout compile returned timed_out at
progress 12 with the hint; re-wait completed with sizes; warm compile and
a full upload each finished in a single wait:true call.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Merged
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
1 participant
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.
First of the v0.6.0 agent-experience series (plan: five pain points from the ESP32-S3 hardware session).
The problem
Compile/upload return a taskId and force the agent into a polling loop via
arduino_task_status— the single biggest orchestration overhead in the toolset. One hardware session rewrote the same polling loop 10+ times.The fix
arduino_compileandarduino_uploadacceptwait: true+timeout_seconds(default 60, clamp 5–600).arduino_task_statusgains the same params to block on in-flight tasks.A timeout is not an error. It returns
{taskId, status, progress, progressMessage, timed_out: true, hint}, so a long first build is simply re-waited:Internals: runners' completion promises (previously discarded via
setImmediate) are kept in ataskPromisesmap;waitForTaskraces completion vs timer. Tasks gaincreatedAt/startedAt/finishedAt. Fully backward compatible — no-wait calls behave as before.Verified on hardware (ESP32-S3, COM6)
timed_out: trueat progress 12 with re-wait hinttask_status {wait:true}→ blocked tocompletedwith section sizeswait:true→ one-shot completedwait:true→ one-shot compile+flash+verify, board running the sketch🤖 Generated with Claude Code
EOF