Contact Information
No response
MaxKB Version
v2.4.1、v2.10.5
Problem Description
定义一个工作流：
测试：
函数换一下：
再换成这个：报错
再想办法绕过去：
以上几种情况均为2.10.5报错
PostgreSQL 内部 C 语言字符串以 \0 作为结束标记，因此文本字段禁止原生保存 ASCII NUL (0x00) 字符。只要字符串里存在 \0，执行 INSERT / UPDATE 就抛出该异常。
上面的异常估计是后面版本改了，再早期版本2.4.2中的报错是：
PostgreSQL text fields cannot contain NUL (0x00) bytes
在工具中也是：
能否在工作流、知识库、工具等工作流对外输出提供服务的地方，对这些空字符做一下过滤？使得存在也不报错？（比如之前过滤掉再入库）
否则函数、工作流某个节点等地方从上游有个这种字符过来，或者是在某个节点弄了这个字符，导致用户使用起来报错，偶然又不报。
手动分析也不合理，目前复现出来的工作流有100多个节点，不可能手动分析的，如果做不到，能不能加一个日志记录一下，到底哪个细节节点（比如执行到xx工具）出来的？
Steps to Reproduce
The expected correct result
No response
Related log output
Additional Information
No response
Contact Information
No response
MaxKB Version
v2.4.1、v2.10.5
Problem Description
定义一个工作流：
测试：
再换成这个：报错
再想办法绕过去：
以上几种情况均为2.10.5报错
PostgreSQL 内部 C 语言字符串以 \0 作为结束标记，因此文本字段禁止原生保存 ASCII NUL (0x00) 字符。只要字符串里存在 \0，执行 INSERT / UPDATE 就抛出该异常。
上面的异常估计是后面版本改了，再早期版本2.4.2中的报错是：
PostgreSQL text fields cannot contain NUL (0x00) bytes
在工具中也是：
能否在工作流、知识库、工具等工作流对外输出提供服务的地方，对这些空字符做一下过滤？使得存在也不报错？（比如之前过滤掉再入库）
否则函数、工作流某个节点等地方从上游有个这种字符过来，或者是在某个节点弄了这个字符，导致用户使用起来报错，偶然又不报。
手动分析也不合理，目前复现出来的工作流有100多个节点，不可能手动分析的，如果做不到，能不能加一个日志记录一下，到底哪个细节节点（比如执行到xx工具）出来的？
Steps to Reproduce
The expected correct result
No response
Related log output
Additional Information
No response