deps(flutter): bump image from 4.7.2 to 4.8.0#10
Open
dependabot[bot] wants to merge 1 commit into
Open
Conversation
Bumps [image](https://github.com/brendan-duncan/image) from 4.7.2 to 4.8.0. - [Changelog](https://github.com/brendan-duncan/image/blob/main/CHANGELOG.md) - [Commits](https://github.com/brendan-duncan/image/commits/v4.8.0) --- updated-dependencies: - dependency-name: image dependency-version: 4.8.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
Author
LabelsThe following labels could not be found: Please fix the above issues or remove invalid values from |
physercoe
pushed a commit
that referenced
this pull request
May 23, 2026
…'t go stale (v1.0.653-alpha) ADR-035 W11 fix-up wedge #10 — the load-bearing MCP fix. ## Symptom agy's tools/call on termipod fails with `connection closed: calling "tools/call": client is closing: invalid request` even though `tools/list` was cached fine and the hub-mcp-bridge binary works end-to-end from the shell. Same agy session can reach the agytest MCP server without trouble. ## Root cause: stale-token persistence agy 1.0.1 reads MCP configs from TWO files and merges them, with WORKDIR winning on same-server-name conflicts: - GLOBAL — ~/.gemini/config/mcp_config.json - WORKDIR — <cwd>/.mcp.json agy auto-syncs the workdir copy from global on FIRST read of a new workspace, then never re-syncs. The previous antigravity launch paths (v1.0.640..v1.0.652) wrote the global config with the fresh per-spawn MCP token but never wrote the workdir copy. So a workdir .mcp.json from a prior session pinned the OLD token forever; every tools/call from the new spawn went out through hub-mcp-bridge carrying the dead token, the hub returned 401 invalid mcp token, and agy classified the response as "invalid request → client is closing". agytest kept working because it lives only in the global config — no workdir entry to go stale. ## Fix launch_m4_antigravity.go now writes the workdir .mcp.json in addition to the global mcp_config.json at every spawn, mirroring M2's pattern for claude-code. writeMCPConfig is idempotent and overwrites any prior copy, so the token stays current across respawns. Both writes are best-effort: a failure degrades to "no hub MCP" but the agent still launches. Lock test: TestWriteMCPConfig_OverwritesStaleToken pre-populates a workdir .mcp.json with a stale token, calls writeMCPConfig with a fresh one, asserts the fresh token wins. ## On agy's diagnosis agy proposed the env-var block in .mcp.json's "env" field wasn't being propagated to the bridge process — built a wrapper script with baked env vars as workaround. That diagnosis is WRONG (env-var propagation works fine; the workdir .mcp.json content was correct shape, just with the wrong token value). agy was right the bridge was unhappy and the connection was marked permanently closed; it just localised one level too high. Verify-don't-guess discipline meant we re-checked the actual config files before adopting the wrapper workaround, and the file comparison surfaced the real cause. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
physercoe
pushed a commit
that referenced
this pull request
May 24, 2026
…e drops text/thought replays (v1.0.666-alpha) ADR-027 W11 fix-up wedge #10 — the load-bearing one. Closes the "mobile shows nothing for M4" investigation that opened at v1.0.662 and survived four diagnostic wedges. The M4 adapter's runLoop stamped `replay: true` on every event when TailMode == StartFromBeginning (the default). Mobile's agent_feed.dart:749 unconditionally drops kind=text + kind=thought events with replay:true (the M1 ACP session/load dedup path). Every assistant reply, every Thinking… from M4 was silently nuked on the client. lifecycle + input.text + turn.result + usage all rendered fine because they're different kinds; only text/thought were filtered, which made the symptom look like "nothing works" when in fact 4 out of 5 event kinds were arriving. The replay tag is redundant for M4 anyway: - SSE delivery is seq-gated (since=<maxSeq>) — events mobile already cached aren't redelivered. - ID dedup catches anything else (hub event IDs are stable across cold-open + live tail). Mobile-side replay filter stays as-is — useful for the M1 path it was designed for. Diagnosis trail: 5 wedges to find one bug. v1.0.661 dropped noise that was masking the symptom. v1.0.662 added per-message usage. v1.0.663 dropped real but unrelated bugs (dup user_input, state_changed, dup hooks). v1.0.664 raised post-failure log to Warn. v1.0.665 added HOSTRUNNER_LOG_LEVEL=debug. v1.0.665's debug-level posting log proved every event reached the hub. Direct curl against the remote hub confirmed all 5 events lived in agent_events with correct session_id. That left mobile filter as the only remaining suspect — and the replay filter, designed for a totally different driver, was the culprit. Test updated: TestAdapter_Start_ReplaysExistingThenLive now asserts "replay tag MUST be absent" — inverse of the prior assertion that locked the buggy behaviour in. Root cause class: cross-driver feature reuse without checking the consumer. M1 had a real need for the replay tag (session/load re-emits historical events with new IDs); the convention got propagated to M4 where strictly-monotonic JSONL tailing + stable seq + stable IDs make it redundant — and harmful given mobile's drop-on- replay rule. 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 image from 4.7.2 to 4.8.0.
Changelog
Sourced from image's changelog.
... (truncated)
Commits
You can trigger a rebase of this PR by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)