Add synthetic display message hook for middleware#88
Merged
Conversation
- can be created by middleware - like ask_user responses being displayed as a user message in conversation - also system "notification" style messages like "User cancelled"
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.
Problem
Middleware sometimes needs to record user-facing transcript entries that don't correspond to a
LangChain.Messagefrom the LLM. Two concrete cases:ask_usermiddleware needs the user's answer to appear in the conversation as a user message, even though it never went through the model as a user message (it's a tool response).There was no supported path for middleware to persist these entries through the same display-message pipeline that LLM-generated messages use, and therefore no way to get them broadcast to LiveViews via the existing
:display_message_savedevent.Solution
Add a public AgentServer API that middleware can call to persist a synthetic display message, plus an optional callback on the
DisplayMessagePersistencebehaviour that integrators implement to actually write it.Sagents.AgentServer.save_synthetic_message_from/2casts to the AgentServer, which routes the request to the configured persistence module and broadcasts the saved record as{:display_message_saved, msg}— the same event LiveViews already subscribe to for LLM messages.save_synthetic_message/3callback is declared optional on the behaviour, so existing implementations don't break. AgentServer checksfunction_exported?/3before calling and logs a warning if missing.{:error, _}or raised exceptions) are logged but never propagate — synthetic messages are a transcript convenience and must not destabilise the agent.priv/templates/display_message_persistence.ex.eex) gets a default implementation that delegates to the integrator'sConversationscontext, so newly generated projects pick this up automatically.Changes
lib/sagents/agent_server.ex— Addedsave_synthetic_message_from/2public API,:save_synthetic_messagecast handler, and themaybe_save_synthetic_and_broadcast/2helper that gates on persistence + conversation_id, checks the optional callback, and rescues errors.lib/sagents/display_message_persistence.ex— Addedsynthetic_message_attrstypedoc andsave_synthetic_message/3optional callback with full@doccovering parameters, return shape, and the broadcast contract.priv/templates/display_message_persistence.ex.eex— Default generated implementation delegating toConversations.append_display_message/3, with a{:error, :no_conversation}guard for missingconversation_id.test/sagents/agent_server_synthetic_message_test.exs— New test module covering the happy path, both no-op cases (missingconversation_id, missing persistence module),{:error, _}returns, and rescued exceptions.test/support/test_display_message_persistence.ex— ExtendedTestDisplayMessagePersistenceForwardingwithsave_synthetic_message/3plusset_synthetic_response/1andclear_synthetic_response/0helpers driven via:persistent_term, so a single test module can simulate ok/error/raise outcomes.Testing
mix test test/sagents/agent_server_synthetic_message_test.exscovers all five scenarios listed above. No live API calls — the forwarder persistence module substitutes for a real implementation and asserts the AgentServer's behaviour around it.