Skip to content

Preserve ToolCallResult input in AG-UI replay fallback - #1037

Merged
kojiwakayama merged 3 commits into
mainfrom
fix/agui-tool-result-input-fidelity
Apr 14, 2026
Merged

kojiwakayama merged 3 commits into
mainfrom
fix/agui-tool-result-input-fidelity

Conversation

@kojiwakayama

Copy link
Copy Markdown
Contributor

Summary

  • preserve ToolCallResult.input when AG-UI replay attaches after prior tool events were missed
  • use result-level input only as a fallback when the decoder has no earlier tool-call state
  • add a regression test for the replay-missed-tool-start case

Problem

The shared AG-UI decoder synthesized {} for tool input when a ToolCallResult arrived without a prior ToolCallStart / ToolCallArgs sequence, even if the result payload already contained the original input. That dropped replay fidelity for reconnect and snapshot-restore flows.

Testing

  • deno test src/chat/ag-ui.test.ts
  • deno check src/chat/ag-ui.ts

The shared AG-UI decoder dropped ToolCallResult.input when replay attached after ToolCallStart/ToolCallArgs were missed. In that case it synthesized a generic tool input of , which erased the tool context that the sender had already provided on the result payload. This change accepts optional result-level input and uses it only when no earlier tool-call state exists.

Constraint: Preserve the existing replay path for normal ToolCallStart/ToolCallArgs sequences and only use ToolCallResult.input as a fallback when the decoder lacks prior tool state
Rejected: Always trust ToolCallResult.input over accumulated ToolCallArgs | would risk overriding richer streamed args on normal runs
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: When AG-UI replay lacks prior tool-call state, use ToolCallResult.input as the fallback source of truth instead of inventing an empty input object
Tested: deno test src/chat/ag-ui.test.ts; deno check src/chat/ag-ui.ts
Not-tested: end-to-end replay through veryfront-studio after publishing the updated package
The failing Quest/CI browser pipeline was not caused by the AG-UI decoder patch.
The red job died during Playwright's `--with-deps` install step because the runner could not reach archive.ubuntu.com over IPv6, so Chromium's OS packages never installed.
Our browser helpers only require the Chromium executable in CI, and the runner image already has the needed shared libraries for the passing binary browser job.

Constraint: Keep the browser test jobs installing the Playwright Chromium binary while removing the flaky apt-based system dependency path
Rejected: Retry the same `--with-deps` install step | would keep the pipeline coupled to external apt mirror reachability and IPv6 routing
Confidence: medium
Scope-risk: narrow
Reversibility: clean
Directive: CI browser jobs should prefer deterministic browser-binary installs over apt-based dependency bootstrap when runner images already satisfy Playwright runtime libs
Tested: Exact failing GitHub job log reviewed (tests rsc browser e2e); local targeted AG-UI decoder tests still green
Not-tested: Fresh GitHub CI rerun after workflow update
The first workflow adjustment removed `--with-deps`, which got us past the apt mirror failure but exposed the real browser-launch requirement: the runner still needs shared libraries such as libnspr4.so. The root cause remained runner networking, not AG-UI code. This change restores Playwright's dependency install and forces apt onto IPv4 so the package step no longer depends on broken IPv6 reachability.

Constraint: Keep the browser E2E jobs installing the Chromium system dependencies required by Playwright on veryfront-k8s-runners
Rejected: Keep binary-only browser installs | browser launch still failed with missing shared libraries (libnspr4.so)
Rejected: Keep plain `--with-deps` | apt was failing to reach archive.ubuntu.com over IPv6 on these runners
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Browser CI jobs on these runners should force apt to IPv4 before Playwright `--with-deps` installs unless runner networking is fixed upstream
Tested: Exact failing GitHub job logs reviewed before and after the first workflow change
Not-tested: Fresh GitHub CI rerun after the IPv4-forced apt change
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant