记一次odoo 运维事故

事故起因:

stock.move.line 中没有配置多公司访问规则, 于是就手动配置了一个, 由于这个模型没有company_id 字段, 于是就从stock.move 中获取,就会配置出如下的domain

('move_id.company_id','child_of',[user.company_id.id])

配置完成后测试功能很正常, 并且实现了公司筛选

事故描述:

刚开始有用户反应, 订单确认慢, 以为是网络问题, 而且最后也是确认了, 就没有在意

过了一段时间,其他用户也反应订单确认慢了, 我就觉得这事不简单了,自己测试, 也发现确认一张订单需要5分钟, 崩溃

事故排查:

查看后台日志,会出现如下错误, 查看sql 日志,也有类似的语句阻塞, 直接取消,

2025-07-10 22:13:56,063 12136 ERROR odoo_wastonerp odoo.sql_db: bad query: INSERT INTO "mail_followers" ("id", "partner_id", "res_id", "res_model") VALUES (nextval('mail_followers_id_seq'), 23085, 128045, 'sale.order') RETURNING id

ERROR: duplicate key value violates unique constraint "mail_followers_mail_followers_res_partner_res_model_id_uniq"

DETAIL: Key (res_model, res_id, partner_id)=(sale.order, 128045, 23085) already exists.

有怀疑是订单订阅功能的问题, 尝试注释一以下语句,但是不起作用, 而且这部分逻辑没有做过调整

for order in self.filtered(lambda order: order.partner_id not in order.message_partner_ids):
order.message_subscribe([order.partner_id.id])

后来查看sql日志,发现有如下sql 一直在跑,但是又不知道怎么来的, 哪里的代码触发的,而且查询出来的结果也确实很多, 68w, 一次读取完肯定要花很长时间, 后边注意到查询条件里有company_id, 才想起今天有改规则, 主要这个规则是通过页面配置的方式,而不是调整代码, 很难想起来:

SELECT "stock_move".id FROM "stock_move" LEFT JOIN "stock_picking" as "stock_move__picking_id" ON ("stock_move"."picking_id" = "stock_move__picking_id"."id") WHERE ("stock_move"."company_id" in (2)) ORDER BY "stock_move__picking_id"."priority" DESC,"stock_move__picking_id"."date" ASC,"stock_move__picking_id"."id" DESC,"stock_move"."sequence" ,"stock_move"."id"

总结

发生事故,如果不能定位问题, 及时回忆下今天干了什么, 即使是很小的改动, 同时工作日志也很重要