Schedule 触发器不携带任何 org 上下文——定时 runAs:'system' 清扫在多组织部署里仍会产出 organization_id=NULL 的行(#5494 的用户缺席半边)

[hotlong]

PR #6153(修 #5494)把 runAs:'system' 运行的三列染色收口到「引擎知道就染」:触发上下文带 user/org 的运行(手动触发、record-change、带鉴权的 api 触发)三列全染。但 schedule 触发器本身不供给任何 org:

// packages/triggers/trigger-schedule/src/schedule-trigger.ts(handler 内)
const ctx: AutomationContext = {
    event: 'schedule',
    params: { jobId, flowName, schedule },
};

没有 tenantId,引擎无从染 organization_id。于是 #5494 Impact 一节点名的主形态——定时清扫(生产里 sweep 是按 schedule 火的,不是手动)——在多组织部署里仍会把行生在组织分区之外:(organization_id, …) 唯一索引跨 NULL 不生效,org 作用域查询看不见(hotcrm#698 的重复编号证据即此类)。created_by/owner_id 在无用户运行下保持 NULL 是 ADR-0118 D1 的既定表示(PR #6153 已论证并钉住),org 不同:org 不是 actor 列,「这行属于哪个组织」对定时清扫是有真实答案的,只是当前没有任何声明面能把答案交给触发器。

需要一个设计裁决:定时流程的 org 从哪来。候选:

1. flow 元数据的存储 org(org overlay 的流程天然归属其 org;平台级流程无 org → 维持不染);
2. schedule 绑定面新增显式 org 声明(作者声明,publish 校验);
3. 每-org 各火一次(Salesforce 式 per-org scheduling,改动最大);
4. 维持现状 + lint:多组织部署里,含 create_record 的 schedule 流程若未在 fields 显式给 organization_id / owner_id,发布时警告或拒绝(不新增运行时语义,author-time 收口,与 fix(security): surface schedule/user-less flow runAs fail-open (#1888 follow-up) #2308/Author-time expression validator is blind to registry-injected system columns — record.owner_id / created_at / organization_id are rejected as unknown fields #5378 的既有 lint 面同族)。

单组织部署不受影响(org 列本就 NULL 语义)。与 ADR-0073 M2(automation principal,管 actor 不管 org)正交。

Refs:#5494、PR #6153(修复边界在测试 runas-system-stamping.integration.test.ts 的 user-less 用例里显式钉住)、ADR-0118 D1/D5、ADR-0073 D2/D3、hotcrm#698。查重:仓内无既有单(搜 schedule org tenantId / organization_id schedule flow NULL 均无命中)。

[claude]

Triage: needs-user-decision + domain:services + target:v17. Filed 03:52Z, inside this round's own window; picked up rather than deferred.

Why the decision box and not the queue. The body names four candidate answers to one question — where does a scheduled flow's org come from — and they are not variants of one fix: (1) inherit from the flow metadata's storage org, (2) declare it on the schedule binding, (3) fire per-org, (4) leave runtime semantics alone and reject/warn at publish time. They differ in where the answer is authored, in whether existing scheduled flows change behaviour on upgrade, and in blast radius from a lint rule up to per-org scheduling. That is a product-semantics call on a public contract surface, so it is the maintainer's, not this seat's. Routing was never in question, so nothing here is an escalation of "which repo" — it is an escalation of the underlying product question, which is the sanctioned path.

domain:services — the landing site for every candidate except (4) is packages/triggers/trigger-schedule/src/schedule-trigger.ts, and packages/triggers/* (flow triggers) is on the domain:services row of the SKILL domain table. Candidate (4) would land partly in the publish-time lint surface instead; recording that now, because if the maintainer picks (4) the label should be re-examined rather than inherited.

target:v17 — and this is the part worth arguing rather than asserting. Criterion ③: rows written outside the org partition are a stored-data shape, and a (organization_id, …) unique index does not constrain across NULL, so the damage is duplicate/invisible records that a later fix cannot retroactively repartition. The body also identifies the dominant production shape correctly — sweeps fire on a schedule, not by hand — so PR #6153 closing the engine-side half does not close the case that #5494 was filed for. Multi-org deployments only; single-org is unaffected by construction.

Putting a decision-pending card on the release board is deliberate, not an accident of labelling: it is how the maintainer sees that something needs an answer before the RC, rather than discovering it after. If the full decision cannot fit the v17 window, candidate (4) is the cheap containment — author-time rejection adds no runtime semantics and reuses the existing #2308/#5378 lint surface — and it can ship while (1)–(3) stay open.

Dedup — the filer's search claim re-verified independently, because the search API is unavailable to this seat and their negative result came from a tool this seat cannot reproduce. Full paginated enumeration of open issues and PRs across all three repos. Related but distinct: #5494 (the parent; its engine-side half is PR #6153, which the body correctly reads as not covering the schedule path), ADR-0073 M2 (automation principal — actor columns, explicitly orthogonal to org). No duplicate; no shadow in objectui or cloud.

One boundary this seat endorses on the evidence. The body's distinction is the load-bearing one and should survive into whatever gets decided: created_by / owner_id staying NULL under a user-less run is settled representation (ADR-0118 D1, pinned by PR #6153), whereas organization_id is not an actor column — "which org does this row belong to" has a real answer for a scheduled sweep, and today no declaration surface exists to carry it. The decision is about building that surface, not about revisiting D1.

本评论来自分诊座位 Routine(#5474 试点),不构成认领。

---

Generated by Claude Code