fix(tsagentspec): accept plugin components nested inside builtin components - #259
Open
fede-kamel wants to merge 1 commit into
Open
fix(tsagentspec): accept plugin components nested inside builtin components#259fede-kamel wants to merge 1 commit into
fede-kamel wants to merge 1 commit into
Conversation
…onents Component fields of builtin components were typed with closed Zod discriminated unions of the builtin component schemas, so a plugin component (e.g. a FunctionTransform in an Agent's transforms, or a ConnectorToolBox in its toolboxes) was rejected with "Invalid discriminator value" both by the factories and, after the nested component had been deserialized by its plugin, by the builtin Agent deserialization. Documents produced by the serializer with custom plugins could therefore not be read back (oracle#219). component.ts now derives ComponentTypeName from a runtime list of the builtin component type names and adds openComponentUnion(): builtin component types are still validated by the builtin union, while components with a non-builtin componentType are validated against CustomComponentSchema (base component fields only, other fields kept). The helper is applied to every component-container field: Agent llmConfig/tools/toolboxes/transforms, SpecializedAgent additionalTools, ToolNode tool, AgentNode agent, LlmNode llmConfig, the Flow node references, MCPTool/MCPToolBox clientTransport, OciGenAiConfig clientConfig, the summarization transforms' llm/datastore and the Oracle datastore connectionConfig. Factories accept the same components so construction and deserialization stay symmetric, and a builtin component of the wrong kind is rejected exactly as before. Fixes oracle#219. Signed-off-by: Federico Kamelhar <federico.kamelhar@oracle.com>
oracle-contributor-agreement
Bot
added
the
OCA Verified
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
1 participant
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.
Fixes #219.
Root cause
Every component-container field of the builtin TypeScript components (
Agent.tools/toolboxes/transforms/llmConfig,ToolNode.tool,AgentNode.agent,LlmNode.llmConfig, the Flow node union, MCPclientTransport, OCIclientConfig, transformllm/datastore, Oracle datastoreconnectionConfig) was a closedz.discriminatedUnionof the builtin schemas. A plugin could serialize and deserialize its own component, but the builtin factory then re-validated the parent against the closed union and threwZodError: Invalid discriminator value. Registering a replacement plugin for the builtin parent is not possible because duplicate component types are rejected.Changes
src/component.ts:ComponentTypeNameis derived from a runtimeBUILTIN_COMPONENT_TYPE_NAMESlist; newisBuiltinComponentTypeName,CustomComponentSchema(base fields validated, extra fields passed through, builtin type names refused) andopenComponentUnion(union), a Zod transform that dispatches oncomponentType: builtin names go through the original union (so a wrong-kind builtin still fails with the same message), any other registered name goes throughCustomComponentSchema.NodeUnion; factory option types widened accordingly. New symbols exported fromsrc/index.ts.tests/serialization/nested-custom-components.test.ts: the scenario of the issue (custom transform, toolbox and tool inside anAgent; custom node and custom tool inside aFlow/ToolNode) through both the factories and the serializer round trip, plus a check that a wrong-kind builtin is still rejected. Six of the seven tests fail onmain.tests/component-registry.test.tsasserts the name list matches the schema map.Behaviour change to be aware of
Public output types widen from e.g.
Tool[]to(Tool | CustomComponent)[], which is the honest type of the values now accepted. Consumers narrowing oncomponentTypeliterals keep working for builtin names.Verification
From
tsagentspec/:npm test51 files / 745 tests passed (737 onmain),npm run lintclean,npm run buildsucceeds.