[GH-ISSUE #98] Emit meaningful MCP progress and propagate cancellation through owned analysis work

bsakaguchi commented

2026-10-15 18:20:44 +00:00

Owner

Originally created by @morluto on GitHub (Jul 13, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/98

Summary

Add semantic MCP progress and end-to-end cancellation for synchronous REA operations first, then reuse the same primitives from task-backed execution in #97.

This issue must not wait for MCP Tasks. Ordinary tools/call progress tokens and request cancellation provide immediate value and establish the provider-neutral cancellation boundary Tasks will later consume.

Current state in REA 1.3.0

REA improved Hopper shutdown: it stops background analysis, waits, closes only the session-owned document, and verifies acknowledgement.
Process capture already models owned process groups and cleanup.
There is no general MCP progress emission.
Cancellation is not consistently propagated through Hopper work, hashing, mounts, extraction, replay peers, comparison, or verification.
No shared AbortSignal-style application boundary connects MCP cancellation to providers.

User problem

Long operations can appear hung. When a user cancels, agents cannot prove whether:

Hopper stopped;
descendant processes exited;
native mounts were released;
replay servers closed;
artifact hashing stopped;
temporary roots were removed;
partial evidence is valid or must be discarded.

Proposed design

Progress

Create a provider-neutral progress reporter with:

phase identifier;
human-readable safe message;
completed and optional total units;
optional unit name;
monotonic sequence;
bounded update frequency;
final completion/failure/cancellation state.

Suggested progress units:

Operation	Phases and units
Hopper analysis	load, analyze, index; procedures completed/total when available
Artifact inventory	occurrences scanned, bytes hashed, containers traversed
Extraction	selected occurrences and bytes written
Process capture	elapsed/timeout, frames, process samples, protocol events
Function/bundle comparison	dimensions/pages evaluated
Reconstruction verification	claims evaluated/total
Cross-version investigation	left inventory, right inventory, comparison, changed-behavior report, checkpoint

Do not fabricate totals when providers cannot observe them.

Cancellation

Thread one cancellation signal from transport to application service and provider. Each owned subsystem must define:

cancellation checkpoint behavior;
cleanup action;
cleanup verification;
whether partial output is discarded, returned as truncated, or retained as evidence;
safe error/category projection.

Result semantics

Cancellation is distinct from timeout and failure.
A cancelled request must not later publish a successful result.
Partial evidence must explicitly say truncated/cancelled and identify limitations.
Cleanup failure must remain visible even when the primary operation was cancelled.

Acceptance criteria

Eligible synchronous MCP calls accept a progress token and emit bounded monotonic progress.
Progress uses meaningful phases and observed units; unavailable totals remain unknown.
Client request cancellation reaches a shared application cancellation signal.
Hopper analysis, artifact inventory/hashing, extraction/mounting, process capture, protocol replay, comparison, and reconstruction verification observe cancellation.
Owned process groups, mounts, replay peers, Hopper documents, and temporary roots are cleaned and verified.
Cancellation is distinguishable from timeout, provider failure, and user decline.
A cancellation race cannot produce both cancelled and successful terminal states.
Partial evidence is never presented as complete.
CLI operation remains functional without an MCP progress token and handles SIGINT through the same cancellation boundary.
#97 can reuse the same progress and cancellation interfaces for Tasks.
Tests cover cancellation before start, during every major phase, immediately before completion, cleanup failure, repeated cancellation, and late provider responses.
Documentation explains which phases are cancellable and what partial evidence may survive.

Non-goals

Generic debug logging over MCP.
Fake percentage estimates.
Tasks storage or polling; tracked in #97.
Killing processes not proven to be owned by the active operation.

Dependencies and relationships

Complements the ownership work delivered in REA 1.3.0.
Provides primitives required by #97.
Process-capture policy remains governed by #96.

Originally created by @morluto on GitHub (Jul 13, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/98 ## Summary Add semantic MCP progress and end-to-end cancellation for synchronous REA operations first, then reuse the same primitives from task-backed execution in #97. This issue must not wait for MCP Tasks. Ordinary tools/call progress tokens and request cancellation provide immediate value and establish the provider-neutral cancellation boundary Tasks will later consume. ## Current state in REA 1.3.0 - REA improved Hopper shutdown: it stops background analysis, waits, closes only the session-owned document, and verifies acknowledgement. - Process capture already models owned process groups and cleanup. - There is no general MCP progress emission. - Cancellation is not consistently propagated through Hopper work, hashing, mounts, extraction, replay peers, comparison, or verification. - No shared AbortSignal-style application boundary connects MCP cancellation to providers. ## User problem Long operations can appear hung. When a user cancels, agents cannot prove whether: - Hopper stopped; - descendant processes exited; - native mounts were released; - replay servers closed; - artifact hashing stopped; - temporary roots were removed; - partial evidence is valid or must be discarded. ## Proposed design ### Progress Create a provider-neutral progress reporter with: - phase identifier; - human-readable safe message; - completed and optional total units; - optional unit name; - monotonic sequence; - bounded update frequency; - final completion/failure/cancellation state. Suggested progress units: | Operation | Phases and units | |---|---| | Hopper analysis | load, analyze, index; procedures completed/total when available | | Artifact inventory | occurrences scanned, bytes hashed, containers traversed | | Extraction | selected occurrences and bytes written | | Process capture | elapsed/timeout, frames, process samples, protocol events | | Function/bundle comparison | dimensions/pages evaluated | | Reconstruction verification | claims evaluated/total | | Cross-version investigation | left inventory, right inventory, comparison, changed-behavior report, checkpoint | Do not fabricate totals when providers cannot observe them. ### Cancellation Thread one cancellation signal from transport to application service and provider. Each owned subsystem must define: - cancellation checkpoint behavior; - cleanup action; - cleanup verification; - whether partial output is discarded, returned as truncated, or retained as evidence; - safe error/category projection. ### Result semantics - Cancellation is distinct from timeout and failure. - A cancelled request must not later publish a successful result. - Partial evidence must explicitly say truncated/cancelled and identify limitations. - Cleanup failure must remain visible even when the primary operation was cancelled. ## Acceptance criteria - [ ] Eligible synchronous MCP calls accept a progress token and emit bounded monotonic progress. - [ ] Progress uses meaningful phases and observed units; unavailable totals remain unknown. - [ ] Client request cancellation reaches a shared application cancellation signal. - [ ] Hopper analysis, artifact inventory/hashing, extraction/mounting, process capture, protocol replay, comparison, and reconstruction verification observe cancellation. - [ ] Owned process groups, mounts, replay peers, Hopper documents, and temporary roots are cleaned and verified. - [ ] Cancellation is distinguishable from timeout, provider failure, and user decline. - [ ] A cancellation race cannot produce both cancelled and successful terminal states. - [ ] Partial evidence is never presented as complete. - [ ] CLI operation remains functional without an MCP progress token and handles SIGINT through the same cancellation boundary. - [ ] #97 can reuse the same progress and cancellation interfaces for Tasks. - [ ] Tests cover cancellation before start, during every major phase, immediately before completion, cleanup failure, repeated cancellation, and late provider responses. - [ ] Documentation explains which phases are cancellable and what partial evidence may survive. ## Non-goals - Generic debug logging over MCP. - Fake percentage estimates. - Tasks storage or polling; tracked in #97. - Killing processes not proven to be owned by the active operation. ## Dependencies and relationships - Complements the ownership work delivered in REA 1.3.0. - Provides primitives required by #97. - Process-capture policy remains governed by #96.

bsakaguchi

2026-10-15 18:20:44 +00:00

closed this issue
added the
area: mcp

enhancement
labels

bsakaguchi commented

2026-10-15 18:20:45 +00:00

Author

Owner

@morluto commented on GitHub (Jul 17, 2026):

Completed on current main. ProgressReporter provides bounded monotonic provider-neutral reporting, mcpProgress adapts MCP tokens, and the ordinary tool registration paths propagate cancellation and progress. CLI SIGINT uses the same AbortSignal model. Progress, MCP, derived-operation race, provider, process, artifact, and investigation tests cover the contract; provider-specific checkpoint omissions should be narrow follow-ups.

@morluto commented on GitHub (Jul 17, 2026): Completed on current main. ProgressReporter provides bounded monotonic provider-neutral reporting, mcpProgress adapts MCP tokens, and the ordinary tool registration paths propagate cancellation and progress. CLI SIGINT uses the same AbortSignal model. Progress, MCP, derived-operation race, provider, process, artifact, and investigation tests cover the contract; provider-specific checkpoint omissions should be narrow follow-ups.

bsakaguchi referenced this issue

2026-10-15 18:22:36 +00:00

[GH-ISSUE #375] Capture Electron main/preload/utility process lifecycle and shell events #221

bsakaguchi referenced this issue

2026-10-15 18:22:38 +00:00

[GH-ISSUE #376] Capture Electron IPC channel/direction/sender/receiver with redacted payloads #225

bsakaguchi referenced this issue

2026-10-15 18:22:56 +00:00

[GH-ISSUE #397] Add Node/Electron V8 inspector runtime observation provider #246

bsakaguchi referenced this issue

2026-10-15 18:28:29 +00:00

[GH-ISSUE #2383] [Tracker] Audit analysis and debugging coverage for the TIOBE top 100 languages (October 2026) #794