事故起因:

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"

總結

發生事故,如果不能定位問題, 及時回憶下今天干了什么, 即使是很小的改動, 同時工作日志也很重要