-- 1.0.539.warnings.ops.sql — GLOBAL HYGIENE WARNINGS(只观测,不阻断) -- -- ⚠️ 本文件【不是】verify。AutoVersionUpdate 不执行 .ops.sql,只执行 .sql -- 与 .verify.sql。这里放的是「本批 writer 管不到、但值得盯」的全库卫生项。 -- 人工执行:mysql < 1.0.539.warnings.ops.sql -- -- 为什么不放进 verify:runner 对 verify 的每个切片都要求返回 1,没有"告警"这一档。 -- 把这两项写成 verify 断言,等于让本批为边界外 writer 的行为背书,一旦对方回归就 -- 阻断本批迁移、拖垮后端启动 —— 那是错误的责任划分,不是更严格。 -- -- 两项都【不影响】Stage-3 身份桥,身份桥完全不经过它们: -- PO.purchase_request_no → PR.pr_no → PR.sales_order_entry_id → mdp_std_so.order_entry_id -- ── WARN_GLOBAL_RECEIPT_INVALID_TENANT ───────────────────────────────────────────── -- 写入者已定位:Plugins/Admin.NET.Plugin.AiDOP/MaterialWarehouse/PurchaseReceiptMdpSyncService.cs -- 批次前缀 S5_PUR_RCT_STD_,属 S5 模块边界(CLAUDE.md 第九节模块边界表) -- 本批只对该表加了 idx_std_rct_po,未接管其写入 SELECT 'WARN_GLOBAL_RECEIPT_INVALID_TENANT' AS `WARNING_CODE`, 'mdp_std_purchase_receipt' AS `TABLE_NAME`, `tenant_id` AS `TENANT`, COUNT(*) AS `CNT`, MAX(`sync_batch_id`) AS `LAST_WRITER_BATCH`, MAX(`update_time`) AS `LAST_WRITE_AT` FROM `mdp_std_purchase_receipt` WHERE `tenant_id` IS NULL OR `tenant_id` <= 0 GROUP BY `tenant_id`; -- ── WARN_GLOBAL_PO_LITERAL_NULL ──────────────────────────────────────────────────── -- mdp_std_purchase_order.work_order 是本批之前就存在的列,本批只做过一次性归一。 -- 实测:租户 838 的 S3_MDP_FULL 批次里,贴源层同批次、同 source_biz_key 的 -- NULLIF(NULLIF(JSON_UNQUOTE(JSON_EXTRACT(raw_data,'$.WorkOrd')),'null'),'') -- 求值结果为 NULL,标准层却仍出现字面量 —— 该值不可能由当前标准层 INSERT 在该批次 -- 产生,写入者尚未定位。登记为 KNOWN ISSUE,不在本批处理。 -- 该列【不作 Stage-3 归因】,归因走 purchase_request_no。 SELECT 'WARN_GLOBAL_PO_LITERAL_NULL' AS `WARNING_CODE`, 'mdp_std_purchase_order' AS `TABLE_NAME`, `tenant_id` AS `TENANT`, COUNT(*) AS `CNT`, MAX(`sync_batch_id`) AS `LAST_WRITER_BATCH`, MAX(`update_time`) AS `LAST_WRITE_AT` FROM `mdp_std_purchase_order` WHERE `work_order` IN ('null', '') GROUP BY `tenant_id`;