Intelligence-mode runs break with strict providers (z.ai GLM / Anthropic): delta-only messages, silent empty replies, LangChain-shaped tool calls in history #199

Activity

1. Hotragn

   added a commit that references this issue on Aug 23, 2026

   Read back only the turns that parse, and say how many did not

   ...

   9e99ec5
2. Hotragn commented on Aug 24, 2026

   

   Hotragn

   on Aug 24, 2026

   Contributor

   More actions

   Went through this against the code because problem 3 overlaps something I had just changed. Reporting
   what I found rather than a patch, including a correction to something I said elsewhere.

   Problem 3, browser half: fixed in #207

   The transcript crash reading toolCall.function.arguments was the same defect as #44.
   app/src/lib/copilot/thread-messages.ts ended stored as Message[] — a cast, not a check — so
   whatever the history store held went to setMessages and then to every projection. #207 parses each
   stored turn against MessageSchema from @ag-ui/core, leaves out the ones that do not parse, and
   says on screen how many were left out. A tool call shaped {id, name, args} fails
   AssistantMessageSchema on toolCalls[].type, so those turns no longer reach a renderer.

   Problem 3, the 400: I think #207 also stops it, and I was wrong to say otherwise

   On #44 I wrote that the run-validation 400 was "a separate change on the server". Reading the runtime,
   I do not think that is right, and the distinction matters for whoever picks this up.

   handleIntelligenceRun uses thread history for nothing but id dedup
   (dist/v2/runtime/handlers/intelligence/run.mjs:116):

   const history = await runtime.intelligence.getThreadMessages({ threadId: canonicalThreadId, userId });
   const historicMessageIds = new Set(history.messages.map((message) => message.id));
   persistedInputMessages = input.messages.filter((message) => !historicMessageIds.has(message.id));

   Which confirms your problem 1 — history is never merged into canonicalInput.messages — and also means
   the 400 invalid_literal, expected "function" at messages.N.toolCalls.0.type is validating
   input.messages, the messages the client sent, not the persisted rows.

   The client's only route to holding those turns was reading them back through the cast above. So with
   #207 the browser drops them on read and never sends them again, and the thread stops being unusable
   without anything changing on the server. If you can retest a wrecked thread on main once #207 lands,
   that would confirm or kill this — it is inference from the code, not something I reproduced, and you
   have the thread with 17 of them in it.

   What #207 does not do: the persisted rows stay malformed, and those turns are gone from the
   transcript rather than repaired — visibly, with a count, but gone. Anything reading that thread's
   history outside the browser still sees them.

   Problem 1 is the one with nowhere in this repo to fix it

   Hydrating canonicalInput.messages is inside handleIntelligenceRun, which OpenBot does not own —
   it comes from @copilotkit/runtime. The seam this deployment does have is the intelligence client:
   getThreadMessages is called by both the run handler and the history endpoint, and OpenBot already
   subclasses CopilotKitIntelligence to override it (server/src/copilot.ts,
   IntelligenceKnowingANewThread, added in #189 so a thread nobody has run reads as empty rather than
   500). But an override there cannot add a user turn to the run input, because the run handler never
   puts history into the input at all — so the fix for problem 1 is upstream in the runtime, or a change
   to what the client sends, not something that seam reaches.

   Worth saying plainly since you offered to test a patch: problem 1 is not fixable in this repository
   without either a runtime change or the surface sending a fuller message list, and the second is a
   design decision about what a follow-up run carries rather than a bug fix.

   The root cause of problem 3 is still open

   Neither #207 nor anything else explains why {id, name, args} got persisted. I checked both
   shipped agents and neither emits that shape: agent-langgraph/src/history.ts:74-80 and
   agent-bot/src/history.ts:63 both read AG-UI's call.function.arguments and convert into their
   framework's args shape for internal use — inbound, not outbound. So the write is happening somewhere
   else, and it only shows up on interrupted runs, which is a strong hint it is the interrupt path
   persisting framework-shaped state rather than AG-UI events.

   If you still have a deployment that reproduces it, the useful capture would be the persisted rows for
   one interrupted run plus which agent produced them — that would say whether this is the platform, the
   runtime's interrupt handling, or a third agent implementation.
3. davidmckayv

   added 3 commits that reference this issue on Aug 24, 2026

   Read back only the turns that parse, and say how many did not

   ...

   7897c63

   Read back only the turns that parse, and say how many did not (#207)

   ...

   342a292

   Refuse a shell the database, show a screen that ended, and unblock a …

   ...

   fb0c797
4. davidmckayv

   closed this as completedin #289on Aug 28, 2026