Guide Feishu sends during streaming card replies#506
Conversation
evandance
left a comment
There was a problem hiding this comment.
Thanks for the rework — moving from runtime routing to the tool-discovery layer is exactly the right call, and the guidance text reads cleanly. One implementation detail to fix before merge.
The raw { type: 'string', description: ... } shape overrides the SDK base Type.Optional(Type.String()) for message: channel extraProperties are spread after the base in buildMessageToolSchemaProps, and without TypeBox's Optional marker both message and text become required across the shared message tool. send with only card/media, react, edit, read etc. would fail tool-input validation.
Bundled channels contribute real TypeBox schemas (Telegram, Slack, Discord all use Type.Optional(Type.X(...))). Switching to Type.Optional(Type.String({ description: FEISHU_SEND_TEXT_DESCRIPTION })) for both fields and dropping the as unknown as cast should do it. Extending the test to assert the composed tool schema's required does not include message or text would pin behavior against future merges.
|
Updated in e81fb62. Changes:
Validation:
Ready for re-review. |
evandance
left a comment
There was a problem hiding this comment.
Thanks for the rework — Type.Optional adoption, the satisfies-based contract, and the composed-schema regression test (asserting required excludes message/text) all land exactly the asks. The TypeBox version bump to align with the SDK is a nice extra. Approving.
Summary
message/text.sendjust to repeat or finalize the same answer while a normal Feishu streaming-card reply is active.sendruntime behavior predictable by avoiding module-scope active-card rerouting.Context
This supersedes #500. The earlier approach routed
feishu.sendthrough a process-local active-card map, which made empty-target sends implicit and fragile. This PR moves the fix to the tool-discovery layer instead.Validation