Coze达梦数据库适配工作流画布疑难问题全复盘

junjun1990822

342人浏览 · 2026-07-14 16:25:19

junjun1990822 · 2026-07-14 16:25:19 发布

Coze达梦数据库适配工作流画布疑难问题全复盘

前言

本次基于开源 Coze 进行工作流开发时，在工作流中配置代码节点，全程遇到 3 层连环隐蔽 Bug：

Python Pyodide 源码编译报错（\n 物理换行打断字符串）
双层 JSON 序列化引发特殊字符解析报错
达梦数据库 TEXT 大字段 超长不报错、直接清空画布

问题现象全部为偶发、无报错、局部生效，极难定位。

一、第一阶段：Python 沙箱执行报错

1.1 原始问题

代码节点接收大模型返回的数据作为参数传入，由于大模型返回的数据中含换行的文本导致python沙箱执行报错，例如：

\n这里是思考过程

直接使用 单层 json.dumps 注入 Python 源码：

args = {"input": "\nHere's a thinking process"}

报错：

SyntaxError: unterminated string literal

原始代码：

if __name__ == "__main__":
    w = os.fdopen(3, "wb", )
    r = os.fdopen(4, "rb", )

    try:
        req = json.load(r)
        user_code, params, config = req["code"], req["params"], req["config"] or {}
        sandbox = Sandbox(**config)

        if params is not None:
        		 # 就是这一行直接通过json.dumps(params) 将整个输入参数作为字符串拼接到python代码中导致报错
            code = prefix + f'args={json.dumps(params)}\n' + user_code + suffix
        else:
            code = prefix + user_code + suffix

        resp = sandbox.execute(code, **config)
        result = json.dumps(dataclasses.asdict(resp), ensure_ascii=False)
        w.write(str.encode(result))
        w.flush()
        w.close()
    except Exception as e:
        print("sandbox exec error", e)
        w.write(str.encode(json.dumps({"sandbox_error": str(e)})))
        w.flush()
        w.close()

1.2 根因（99% 开发者都会误解）

print() 打印看到的 \n 是转义字符展示
Python 编译器会把源码内 \n 解析为真实物理换行
直接导致字符串被换行劈开，源码非法

1.3 初次方案：双层 JSON 序列化

s1 = json.dumps(params)
s2 = json.dumps(s1)
code = prefix + f'args = json.loads({s2})\n' + user_code + suffix

1.4 双层序列化带来的新 Bug（关键踩坑）

双层序列化解决了编译期换行报错，但引入新问题：

前端手动输入 12344\n、带引号、带反斜杠的内容，Pyodide 解析失败

json.decoder.JSONDecodeError: Unterminated string

真实根因

Pyodide 精简解析器 不支持高密度多层转义嵌套：
" + \\n 叠加场景，短文本也会解析错乱、提前截断字符串。

单层：简单转义 → Pyodide 正常
双层：嵌套多层转义 → Pyodide AST 解析 Bug

1.5 最终终极稳定方案（彻底根治沙箱问题）

放弃双层 JSON 序列化，改用 Base64 无损隔离所有特殊字符

优点：

源码中彻底消失 \、"、\n 所有冲突字符
编译 100% 安全
运行时解码还原原始内容，换行、引号、反斜杠完全不丢失

标准最终代码：

# 编码隔离所有特殊字符
params_json = json.dumps(params)
b64_data = base64.b64encode(params_json.encode("utf-8")).decode("utf-8")
code = prefix + f'args = json.loads(base64.b64decode("{b64_data}").decode("utf-8"))\n' + user_code + suffix

prefix 固定依赖：

import json
import sys
import base64
import asyncio

✅ 从此：LLM 超长文本、手动输入、任意转义字符全部兼容

二、第二阶段：工作流画布 Canvas 偶发清空（最隐蔽生产级 Bug）

2.1 现象

调试时：Go 内存 d.Canvas 完整超长 JSON
保存后：数据库 Canvas 偶尔为空字符串
无报错、无异常、无日志警告

2.2 排除误区

不是前端丢失字段：后端入参完整
不是超长截断：达梦 TEXT 支持 2G
不是代码覆盖：调试确认保存前变量正常

2.3 真实根因（达梦数据库独有机制）

坑点 1：达梦默认「行长度限制」

达梦 未开启 LONG ROW 时：

单行所有行内字段总长度 ≤ 页大小 / 2（默认 4000/8000 字节）
TEXT 字段 大于 900 字节会走行外 LOB，但行内仍保留指针占用配额
画布 JSON 稍大 → 整行超限

坑点 2：达梦宽松模式静默失败（最坑）

MySQL 超长：截断 + 警告
达梦超长：直接丢弃内容，字段置空，不报错、不回滚

这就是：调试有值、入库为空、偶发复现的终极原因

坑点 3：GORM `UpdateAll:true` 全量覆盖放大灾难

项目原有 Save 底层：

db.Clauses(clause.OnConflict{UpdateAll: true}).Create(values)

特性：

只要主键冲突，全字段覆盖写入
某次画布超长被达梦置空
下次局部保存（只改 InputParams）
达梦数据库表现为MERGE INTO形式，不会判断字段是否为大字段是否使用long row存储，导致直接判断为字符串，超长的情况下设置为空
空 Canvas 直接覆盖数据库

最终现象：偶发画布清空

三、第三阶段：多数据库兼容约束加剧问题

约束

项目需要兼容：MySQL / SQLite / 达梦
禁止使用 dm.DmClob 专属类型，必须统一 string

隐藏坑

dm-go 驱动原生缺陷：

string 映射 TEXT 超长文本存在解析异常
大 JSON 极易写入空值

四、全套根治解决方案

4.1 达梦数据库层：表开启 LONG ROW

解决单行长度限制，彻底消除超长置空

批量执行相关alter table操作比如：

ALTER TABLE workflow_draft ENABLE USING LONG ROW;

4.2 修复 GORM 致命坑：调整为先查询再执行新建或更新操作

原逻辑：全量覆盖、零值覆盖历史数据
原代码：

if err := r.query.WorkflowDraft.WithContext(ctx).Save(d); err != nil {
	 return vo.WrapError(errno.ErrDatabaseError, fmt.Errorf("save workflow draft: %w", err))
}

新逻辑：先判断是否存在，如果存在则更新否则新建
新代码：

tempDraft, err := r.query.WorkflowDraft.WithContext(ctx).Where(r.query.WorkflowDraft.ID.Eq(id)).Count()
if err != nil {
	return vo.WrapError(errno.ErrDatabaseError, fmt.Errorf("query workflow draft: %w", err))
}

if tempDraft == 0 {
	err = r.query.WorkflowDraft.WithContext(ctx).Create(d)
} else {
	_, err = r.query.WorkflowDraft.WithContext(ctx).Updates(d)
}

if err != nil {
	return vo.WrapError(errno.ErrDatabaseError, fmt.Errorf("save workflow draft: %w", err))
}