deps(flutter): bump flutter_foreground_task from 8.17.0 to 9.2.2#12
Open
dependabot[bot] wants to merge 1 commit into
Open
deps(flutter): bump flutter_foreground_task from 8.17.0 to 9.2.2#12dependabot[bot] wants to merge 1 commit into
dependabot[bot] wants to merge 1 commit into
Conversation
Author
LabelsThe following labels could not be found: Please fix the above issues or remove invalid values from |
Bumps [flutter_foreground_task](https://github.com/Dev-hwang/flutter_foreground_task) from 8.17.0 to 9.2.2. - [Changelog](https://github.com/Dev-hwang/flutter_foreground_task/blob/master/CHANGELOG.md) - [Commits](https://github.com/Dev-hwang/flutter_foreground_task/commits) --- updated-dependencies: - dependency-name: flutter_foreground_task dependency-version: 9.2.2 dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
force-pushed
the
dependabot/pub/flutter_foreground_task-9.2.2
branch
from
2415767 to
e94385a
Compare
physercoe
pushed a commit
that referenced
this pull request
May 23, 2026
ADR-035 W11 fix-up wedge #12 — agy's MCP tools/call STILL failed after v1.0.654's dot-name filter. Different error, same root family. ## Root cause: JSON-RPC 2.0 §4.1 violation JSON-RPC 2.0 §4.1: 'The Server MUST NOT reply to a Notification.' A notification is a request without an `id` field. Our hub's MCP handler had a default-case error path that wrote an error frame for every unknown method — including notifications. agy 1.0.1 sends `notifications/roots/list_changed` to every connected MCP server periodically (host-verified in agytest's stderr log). Our hub fell through to default → wrote a JSON-RPC error response. The bridge piped that to agy's stdin as an unsolicited frame. agy's strict MCP client read the unsolicited frame, classified it as a protocol violation, and closed the stdio transport. Every subsequent tools/call from the LLM hit the dead transport → 'connection closed: client is closing: invalid request'. The same hub also failed for any other notification method we didn't explicitly enumerate (notifications/cancelled, etc.) — notifications/initialized only worked because it had its own case. ## Smoking gun agytest's stderr log captured the exact frame: IN {"jsonrpc":"2.0","method":"notifications/roots/list_changed","params":{}} agytest's permissive Python parser silently ignored it; our strict hub responded with an error. The cross-server log diff (agytest worked, termipod didn't, same input frame) was the load-bearing clue. Manual reproduction: $ echo '{"jsonrpc":"2.0","method":"notifications/roots/list_changed"}' | hub-mcp-bridge {"jsonrpc":"2.0","error":{"code":-32601,"message":"method not found: ..."}} (should have been empty body per JSON-RPC spec) ## Fix Insert a notification gate BEFORE the per-method switch in server/mcp.go. The standalone daemon (hubmcpserver/run.go) already handles this correctly via a 'no id → no reply' branch; only the in-process /mcp/<token> route was buggy. Lock test: TestMCP_NotificationsGetNoResponse exercises 5 notifications including the host-verified notifications/roots/list_changed and an unknown-method case (to confirm the default-path no longer fires for notifications). Each must return 204 with empty body. ## Why agy's prior diagnosis missed it agy proposed three theories — stdout corruption, PATH discrepancy, sandbox restrictions — all wrong. The actual cause was a wire-level frame agy sent AFTER initialize that hadn't been considered. Finding it required reading the agytest server's stderr log (where agy ALSO sent notifications/roots/list_changed) and comparing what agytest's permissive parser ignored vs what our strict-handler responded to. Verify-don't-guess + cross-server log comparison was the load-bearing technique. ## MCP debug arc summary Four wedges, each a distinct layer of the strict-client wall: v1.0.649 — hard-coded protocolVersion → agy 2025-11-25 rejected v1.0.653 — workdir .mcp.json pinned stale token → 401 v1.0.654 — dot-named tool aliases → tools/list batch rejected v1.0.656 — replied to notifications → client closed transport Each surfaced only after the prior was fixed — strict clients fail at the first wall they hit, hiding everything behind it. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
physercoe
pushed a commit
that referenced
this pull request
May 24, 2026
…th token pill (v1.0.668-alpha) ADR-027 W11 fix-up wedge #12. Two M4 polish gaps from v1.0.667 dev-box smoke: context chip works now, but cancel-button stuck after MCP-tool turns + token-flow pill blank. - Cancel-button race: hookStop posted turn.result SYNCHRONOUSLY the moment claude invoked Stop hook — before the JSONL tailer had a chance to read + post the preceding assistant text frame. Wire seq order: turn.result(N) → text(N+1) → usage(N+2). Mobile's _isAgentBusy walks tail-first: usage skip (v1.0.667), text → busy. turn.result at lower seq never reached. Fix: emit turn.result from the JSONL's own system{subtype: turn_duration} frame (LAST frame of a turn, written after text + stop_hook_summary). Now turn.result has the HIGHEST seq, walker hits it first, idle. Dropped turn.result emission from hookStop; FSM transition kept. - Token-flow pill: _TelemetryStrip gates on modelTotals.isNotEmpty, populated only from turn.result.by_model (codex/claude stream-json shape). M4's turn.result has no by_model. Pill suppressed even though usage was flowing. Fix: synthesise a _ModelTokens entry from per-message usage when modelTotals is empty. SET semantics on every field (NOT add) so the pre-v1.0.662 sum-across-tool-use-iterations bug doesn't reappear. Bucket key = per-message model or "claude-code". Tests: TestMapLine_TurnDurationSystemEmitsTurnResult (new mapper shape), TestOnHook_StopOnlyTransitionsFSM (rewrites the "hookStop emits turn.result" assertion to "hookStop posts nothing"). Latency note: turn.result lands ~250ms later than before (one tailer poll-tick after turn_duration frame written), in exchange for deterministic seq ordering against text/usage. Net win — the prior fast-but-out-of-order path left the cancel button stuck. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
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.
Bumps flutter_foreground_task from 8.17.0 to 9.2.2.
Changelog
Sourced from flutter_foreground_task's changelog.
Commits