渠道配置改成功却没留下审计记录，怎样把两次写入放进同一事务

配置更新与同库审计记录应在一个事务里提交。审计写入失败时回滚配置，调用者拿到明确失败；分别提交会留下配置已变、审计为空的不一致状态。

定义一次管理变更的原子范围

审计表常常在主更新之后才写，看起来只是多一条日志，却承担追溯谁改了什么的职责。如果配置已经commit，随后审计因字段缺失或约束失败，再rollback只能撤销当前事务，无法倒回此前提交。调用栈里写了try并不等于所有SQL属于同一个事务。

复现第二次写失败的空档

附件故意向NOT NULL审计字段插入NULL，制造稳定可重现的失败。分开提交的结果是配置为new、审计零行；同一事务的结果是配置仍old、审计零行。失败注入没有调用真实渠道，也不需要通过偶发断网碰运气，两个结果能直接比较。

数据库事务范围应与业务上必须一起出现的事实一致：配置内容、操作者标识和变更摘要通常需要同一次提交。附件将审计约束错误作为故障点，只为了检查原子性，不能作为真实审计格式。提交本身失败时也要返回失败，不能在写完INSERT以后提前向前端宣布成功。

区分同库原子性与外部日志投递

应用还应在事务边界外组装响应，成功提示必须等commit返回以后才发出。若审计位于远程系统，不能把这个单库事务结论直接照搬；可考虑同库待发送事件再异步投递，但那已经是另一种一致性设计。示例不承诺跨库、Redis或消息服务的原子性。

适用范围：只涵盖一个SQLite数据库，不承诺跨Redis、消息队列或远程审计系统原子性。

配套样本与复核入口

• run.py：独立运行程序，包含合成输入、操作和正反例断言。
• case.json：输入说明、预期任务与适用范围，便于保存和交接。
• observed.json：本次实际执行输出；临时路径、进程号和计时可能随运行变化。

下载材料后运行，对照split_commit和atomic_rollback两个数组。前者展示审计失败留下已变配置，后者展示配置被一并撤销；审计行数均为零正好说明故障注入发生了。排查现有代码时可以用无敏感字段建立类似约束失败点，确认响应、日志与事务状态一致，而不是在生产审计表里随便删除字段试验。

Python3.8以上及标准库；使用Python自带SQLite。程序不读取现有网关数据库，全部样本写入内存或新建临时目录，执行完自动清理；没有任何模型API调用。

python -B run.py

阅读输出时，先按case.json中的任务逐项核对网关配置审计原子提交，再与observed.json比较。非零退出表示依赖或断言需要处理，应保留实际错误。

一手依据1（SQLite只允许一个同时写事务；BEGIN/COMMIT/ROLLBACK控制合成表事务范围。）。

继续阅读：批量导入渠道到第三行失败，怎样按既定策略保留成功项或整批回滚；两名管理员先后保存渠道配置，怎样阻止旧页面覆盖新修改；自建网关安全加固：API 网关别裸奔在公网上。