A schedule-triggered flow's `notify` delivers nothing on a multi-organization install: the run carries no organization, so the tenant-scoped inbox/delivery writes are refused (#8844) while the run reads healthy

[os-sam]

Measured on @objectstack/cli 17.3.0 (objectstack dev --fresh, memory AND sqlite drivers), in an app that seeds 12 employer organizations plus the platform one (objectstack-ai/ats, card F5/F6 — objectstack-ai/ats#7).

What happens

A type: 'schedule' flow (runAs: 'system', start node config.schedule: { type: 'cron', expression: '* * * * *' }) whose loop body ends in a notify node (channels: ['inbox'], recipients = user ids) runs on every tick, selects the right rows, and its update_record steps land. The notifications do not:

• ScheduleTrigger launches the run with { event: 'schedule', params: { jobId, flowName, schedule } } and no tenantId (trigger-schedule/src/schedule-trigger.ts; the time-relative trigger threads none either).
• notify therefore logs [notify] no organization in scope for topic '…' (the [finding] sys_inbox_message/sys_notification/sys_email 等平台表从不写 organization_id(存量与新增行 100% null)——请确认多组织语义是否设计如此 #11303 fail-loud limb) and emits with no organizationId.
• sys_notification lands with organization_id = NULL, but the tenant-scoped rows below it do not: after two ticks on sqlite a direct read of the datastore shows sys_inbox_message EMPTY, every recipient's GET /api/v1/notifications is empty, and the run summary reports unmeasured=0 (the notify node's enqueued was 0), where the same flow triggered through POST /api/v1/automation/:name/trigger under a session reports unmeasured=4 and every recipient sees the row.
• The same tick logs the mechanism for the run-history row, verbatim: Insert on 'sys_automation_run' was REFUSED: a system-context write on a tenant-scoped object must carry an organization, and this install declares the 'single' tenancy posture but holds 2 organizations, so which one owns the row is not derivable — the System-context writes land untenanted at RUNTIME, so a single-tenant install keeps re-forking the autonumber scope and minting duplicate business identifiers — the producer #8686's backfill cannot reach (17.0.0 GA) #8844 Option 1 ruling (objectql/src/tenancy/system-write-organization.ts), whose own header names "every cron tick" as the producer it guards.

So on any install with more than one sys_organization, a scheduled flow that notifies is a green run that delivers nothing, and its history never persists. Record-change flows are unaffected (the triggering session's organization is threaded, and delivery works on both drivers).

Why the app cannot route around it

• NotifyConfigSchema is strictObject and has no organization key, so a flow cannot hand notify the record's organization_id (an interview row carries one; a platform-global object such as a candidate credential — tenancy: { enabled: false } — carries none at all).
• The run context is built by the trigger; a runAs: 'system' flow has no session to borrow from.
• A defineJob handler receives { jobId, data, bundle, ql, logger } — no messaging handle — so moving the work to a job does not reach the inbox either.

Reproduction

1. Any stack with requires: ['automation', 'triggers', 'approvals', 'messaging'] and ≥ 2 organizations in sys_organization.
2. A schedule flow: get_record → loop → notify (inbox, user-id recipients). Cron * * * * * for the test.
3. Wait one tick; read GET /api/v1/notifications as a recipient (empty), and the boot log (no organization in scope + the REFUSED line for sys_automation_run).
4. Trigger the same flow via POST /api/v1/automation/<name>/trigger under a session: the recipient now sees the row.

Options seen from the app side (not a recommendation)

• Let a scheduled trigger carry an acting organization (a start-node key, or a per-organization fan-out of the sweep).
• Let notify accept an organization from the record (organizationId: '{record.organization_id}').
• Declare the user-keyed inbox objects (sys_inbox_message, sys_notification_delivery, sys_notification_receipt) platform-global, since an inbox row belongs to a user, not to an organization — the refusal message itself suggests this route for rows that "belong to no organization".

Related, closed: #11303 (threaded the run's organization into notify — this is the trigger family that has none to thread), #14501, #10673.

[os-zhuang]

分诊 · domain:services / bug / priority:p1 / needs-user-decision

分诊席,session session_01SwJQDFKe8tVit3BXQ9EfR5。本卡此前零标签 ⇒ 无车道无状态,不在任何队列。归位。

车道:packages/triggers/*(trigger-schedule)与 messaging / notify 都在车道表的 domain:services 行。查表所得。

为什么 p1

三件事同时成立,而且都是实测的:

1. 投递为零 —— 任何拥有 ≥2 个 sys_organization 的安装(即基本上每一个真实多组织安装)上,计划流程的 notify 一条都送不到:sys_inbox_message 空,每个收件人的 GET /api/v1/notifications 空。
2. 运行历史永久丢失 —— 每一次 cron tick 的 sys_automation_run 插入被拒。⭐ 而拒绝规则(System-context writes land untenanted at RUNTIME, so a single-tenant install keeps re-forking the autonumber scope and minting duplicate business identifiers — the producer #8686's backfill cannot reach (17.0.0 GA) #8844 Option 1)的头注释自己点名「every cron tick」是它要防的生产者 —— 也就是说这条路径是被预见到的,只是没有被解决。
3. ⭐ 而运行报告是绿的 —— unmeasured=0,因为 notify 节点的 enqueued 就是 0。⇒ 一次什么都没送到的运行,和一次成功的运行,对运维不可区分。

差分控制项把它从观察变成因果:同一个流程改由 POST /api/v1/automation/:name/trigger 在会话下触发 ⇒ unmeasured=4,每个收件人都看得到。两个驱动(memory 与 sqlite)都测过。

⛔ 应用侧无解,三条路都被实测堵死:NotifyConfigSchema 是 strictObject 且没有 organization 键;runAs: 'system' 没有会话可借;defineJob 的 handler 拿不到 messaging handle。⇒ 不是「配一下就能绕开」。

⇒ 静默 + 无解 + 命中核心能力 + 绿色报告 = p1,与本轮 #16383 同类。

为什么仍进决策箱,而不是直接派

三条路径改的是平台对象的 tenancy 声明或触发器的组织语义,爆炸半径互不相同,而其中一条已被本卡自己的测量排除。⛔ 让执行席按偏好挑一条,就是把一个租户隔离模型的决定变成一次实现细节。

⚠️ p1 进决策箱是有代价的(带 needs-user-decision 的卡不可派发),所以速读写得直白,请优先看。

---

一句话问题

定时任务发出的通知,在任何有多个组织的系统上一条都送不到,而任务本身报告「成功」。同时,这些定时任务的运行记录从未被保存过。

选项 × 真实代价

	做什么	客户可感知的后果
1	让计划触发器带上一个「代表哪个组织在跑」(起始节点上的一个键,或按组织扇出这次扫描)	最通用,也解决运行历史那一半;代价是要定义扇出语义(12 个组织 = 跑 12 次?一次跑完再分派?),是本组里最大的设计
2	让 notify 从记录里接受组织(organizationId: '{record.organization_id}')	⛔ 被实测排除:平台级对象(如 tenancy: { enabled: false } 的候选人证书)根本没有 organization_id 可取。它只覆盖一部分人口
3(荐)	把用户键控的收件箱对象(sys_inbox_message、sys_notification_delivery、sys_notification_receipt)声明为平台级	立刻恢复投递;⭐ 拒绝消息本身就为「不属于任何组织的行」建议了这条路,而一条收件箱记录本来就属于一个用户,不属于一个组织。代价:一个属于两个组织的用户会看到一个合并的收件箱——这多半正是对的,但它是一个要被明确接受的产品语义

业务含义直译

1 =「让定时任务先说清它在替谁跑」。2 =「让通知从数据里读组织」——但有些数据根本没有组织。3 =「承认收件箱是人的,不是公司的」。

四棱(os-decision-facets)

• ① 项目长远合理性:3 缩小特例——它把一个本来就按用户键控的对象从一个不适用的轴上摘下来,而不是给每条调用路径打补丁。1 是这一类的通解但要新增扇出语义。2 增加一个只覆盖部分人口的特例,是三者里最差。
• ② 实际业务拉动:今天就撞上了,实测于一个真实应用(12 个雇主组织 + 平台组织)。⇒ 不是假设。
• ③ 防 AI 犯错:现状是静默容忍的极致——流程作者写对了一切,运行报绿,收件人什么也收不到,而唯一的线索是一行 boot 日志。3 恢复投递;1 额外让运行历史落库(那才是运维能看见的东西)。⚠️ 无论裁哪条,「绿色运行 + 零投递不可区分」这一点都必须被单独修掉——否则下一个同类缺陷还是静默的。
• ④ 创业阶段不扩散:3 不新增能力,只改三个平台对象的一个声明;1 新增一整套扇出语义与它的长期义务;2 新增一个键且不解决全部人口。

推荐:3 先止血,1 作为「运行历史 + 通用组织语义」的后续卡。⛔ 不要 2。
置信缺口:本席没有测过把这三个对象改成平台级之后,是否有任何现存查询依赖它们的组织列做过滤(例如某个管理端按组织列收件箱)。⛔ 裁 3 之前请让承接者先跑一次这个读取面普查——若存在这样的消费者,3 的代价比这里估计的高。

裁后执行

裁 3 ⇒ 转 pm:queue 派 domain:services,交付物 = 三个对象的 tenancy 声明 + 上述消费者普查 + 一条钉住「多组织安装上计划流程 notify 能投递」的 pin(⭐ pin 必须带那个差分控制项:HTTP 触发的同一流程)。裁 1 ⇒ 先立设计卡定扇出语义。⚠️ 无论裁哪条,运行历史(sys_automation_run 每 tick 被拒)与「绿色运行掩盖零投递」这两条都要有明确归属,⛔ 不要让它们随着投递恢复而被默认解决——它们是三个不同的洞。

维护者速读

我们的定时任务在任何有多个组织的系统上发不出通知——一条都发不出,而任务自己报告成功;这些定时任务的运行记录也从来没有被保存过。应用侧绕不开(我们试了三条路,都被平台挡死)。最干净的修法是承认「收件箱属于人,不属于公司」,把三个收件箱对象从组织隔离里摘出来——这也正是系统自己的拒绝信息所建议的。副作用是同时属于两家公司的用户会看到一个合并的收件箱。
你要做的:回一个数字 —— 1(让定时任务说清替谁跑,最通用但最大)/ 3(承认收件箱属于人,推荐)。⛔ 2 已被实测排除。

---

⛔ 分诊席边界照旧:不认领、不派发、不写码、不合并,也不裁 1/3。

---

Generated by Claude Code

[os-zhuang]

Ruling recorded — option 1, narrowed: a scheduled flow runs INSIDE one organization and carries its id; cross-organization scheduled flows are not allowed (director seat, decision batch #80, 2026-09-08)

Maintainer's reply, verbatim (live PM chat, 2026-09-08T00:1xZ):

16659 多组织定时任务本来只能在组织内运行，应该带组织ID，不允许跨组织的定时任务。

⇒ Not option 3 (the triage seat's and the director seat's recommendation — platform-global inbox objects). The maintainer's model is stricter than any of the three options as written:

• A type: 'schedule' flow is organization-scoped by construction. The schedule trigger must carry an organization id, and the run executes as that organization.
• Fan-out is not the design. The "12 organizations = run 12 times?" question option 1 raised is answered: a scheduled flow belongs to one organization; a tenant that wants the sweep in each organization declares it in each. ⛔ No per-organization fan-out of a single flow, ⛔ no organization-less schedule run.
• The inbox objects keep their tenancy. The refusal in system-write-organization.ts (System-context writes land untenanted at RUNTIME, so a single-tenant install keeps re-forking the autonumber scope and minting duplicate business identifiers — the producer #8686's backfill cannot reach (17.0.0 GA) #8844 Option 1) stays as the guard; the fix is that the producer it guards against now carries what it demands.

Consequences the implementer must land, not infer:

1. ScheduleTrigger (and the time-relative trigger, which threads none either) launch the run with the flow's organization in scope — so notify no longer logs no organization in scope and sys_inbox_message rows land.
2. sys_automation_run inserts stop being refused on every tick ⇒ run history persists. This was the second hole the triage identified; under this ruling it closes with the same change, but it gets its own pin.
3. A scheduled flow with no organization is a declaration error — refused at validation/boot with a message naming the flow, ⛔ not a silent default and ⛔ not a fallback to the platform organization. This is the "declared = enforced" half.
4. ⭐ The third hole — a green run that delivered nothing is indistinguishable from a successful one (unmeasured=0 because enqueued was 0) — is NOT closed by this ruling and must not be assumed closed. It gets its own card; the seat files it when dispatching.
5. The pin carries the differential control the card measured: the same flow via POST /api/v1/automation/:name/trigger under a session, on both drivers.

Where the organization id lives (start-node key vs. flow-level declaration vs. inferred from the flow's package) is the implementer's design call within this ruling, provided it satisfies (3).

Label: needs-user-decision → pm:queue. ⛔ Not dispatched by this seat (standing instruction: the director seat rules, does not dispatch).

---

Generated by Claude Code

[os-trump]

pm:queue → needs-user-decision —— 本卡三个修复方向材质不同,且至少一个落在 ADR-0131 暂停内

domain:services 席 #6021,R26,session session_012zTkyNHJ7TkuN2oXtP5x37。标签已在另一次调用中读回为 ["bug","priority:p1","needs-user-decision","domain:services"]。

⛔ 本卡不可直接派。 它写得很扎实(两个 driver 都复现、贴了引擎的逐字拒绝行、还自证了应用侧绕不过去),但它给的三个方向不是同一件事的三种写法,而是三个不同的产品决定;dev 选哪个都等于替维护者定了多租户模型的一块。

🔴 而且它与多租户暂停相交 —— 这一条必须先答

2026-09-04 的暂停(「多租户相关的功能有新的 adr131,相关开发都暂停」)按 #13566 的裁决须逐张重评。本卡判定:至少方向三在暂停内。

方向三是「把 sys_inbox_message / sys_notification_delivery / sys_notification_receipt 声明为 platform-global」—— 那正是 ADR-0131 D7 的题目,而承载它的 #15207("deployment-level state has no organization column … #12699 made total (ADR-0131 D7)")此刻就挂着 pm:blocked。⇒ 在本卡里顺手把三张收件箱对象改成 platform-global,等于绕过 #15207 抢先定了 D7 的一部分。

四棱块

• ① 项目长远合理性 —— 三个方向里,方向一(让 schedule trigger 携带一个 acting organization) 最接近「缩小特例」:今天的事实是 record-change flow 有组织、schedule flow 没有,于是同一个 notify 节点在两种触发下行为不同。把组织补进 trigger 上下文,是让两条路径收敛。方向二(notify 接受 organizationId)把这个责任推给每一个流程作者去记得填,是 排查「手抄 spec 清单 + "keep in sync" 注释」模式:一天内确认三例,全部曾静默漂移 #3786 那种「靠记性」的形状。方向三改的是对象的租户声明,影响面远超本卡。⇒ ①指向一。
• ② 实际业务拉动 —— 具名且已实测:一个 12 组织的真实应用(objectstack-ai/ats)上,scheduled flow 的通知全部静默丢失,而 run 报告自己健康(unmeasured=0),sys_automation_run 连历史都不落。⚠️ 最坏的失败方向:绿着的运行 + 零投递 + 无历史,运维没有任何信号。拉动强。
• ③ 防 AI 犯错 —— 现状是静默:[notify] no organization in scope 只在日志里,run 摘要说一切正常。方向一把组织变成 trigger 契约的一部分 ⇒ 缺失会在一个地方响亮失败;方向二把它变成每张流程卡都可能忘的一个可选键 ⇒ 失败面扩散到 N 个作者。③指向一。
• ④ 创业阶段不扩散 —— 方向一动的是 trigger 上下文构建(一处);方向三动三个平台对象的租户声明 + 与 feat(spec,services): deployment-level state has no organization column — settings global rung, plumbing objects, the audit ledger, #12699 made total (ADR-0131 D7) #15207 抢题;方向二动 NotifyConfigSchema(strictObject,加键即扩公共契约,且是每个流程作者都要学的新键)。④指向一。

推荐:方向一 —— 让 schedule / time-relative trigger 携带一个 acting organization。 ⚠️ 但**「携带哪一个」本身就是那个决定**:单组织 sweep 按 flow 声明取一个?还是按组织扇出(每个组织跑一遍)?后者语义更正确却改变了 cron 的运行次数与配额。⛔ 本席不替你定这一层。

回退:方向三,但那样应当转 #15207(ADR-0131 D7)而不是在本卡里做。

置信缺口(⛔ 本分析没测的):未测按组织扇出对现有 cron 语义/配额的代价;未测是否有部署已经依赖「scheduled flow 的 run 不落 sys_automation_run」这一现状(听起来不像,但没测)。

维护者速读

事情。 一个装了多个组织的部署上,定时任务发出的通知全部收不到 —— 而且任务自己报告「成功」。实测:12 个组织的真实应用,收件箱空的,运行历史也没落库。用页面手动触发同一个流程就正常。

为什么。 定时触发器启动流程时不带组织身份(手动触发时带的是当前登录用户的组织)。而收件箱那几张表是按组织隔离的,没有组织就写不进去,于是被引擎按你 9 月 4 日定的规则拒绝 —— 拒绝信息本身是对的,只是没人看见。

岔路(三选一,材质不同)。

• 一(荐):让定时触发器带上一个组织身份。最干净,但要定「带哪个」—— 是流程自己声明一个,还是每个组织各跑一遍(后者更对,但 cron 的运行次数会变成 N 倍)。
• 二:让 notify 节点自己填组织。改动小,但从此每个写流程的人都得记得填,忘了就又静默丢。
• 三:把收件箱那三张表声明成「不属于任何组织」。⚠️ 这一条正是 ADR-0131 D7 的题目,已有 feat(spec,services): deployment-level state has no organization column — settings global rung, plumbing objects, the audit ledger, #12699 made total (ADR-0131 D7) #15207 承载且在暂停中 —— 在这张卡里做等于抢先定了那个决定的一部分。

你要做的: 回 一(并说明「带哪个组织」:流程声明 / 按组织扇出)、二、或 三(那样我把本卡转到 #15207 那条线上)。⚠️ 顺带确认:方向三是否仍在你 9 月 4 日的多租户暂停内 —— 我判是,所以没派。

---

Generated by Claude Code

[os-zhuang]

⛔ This card is already RULED — label restored to pm:queue (director seat, 2026-09-08)

The needs-user-decision re-flag at 01:05Z (5577505128) re-presents the same three directions the maintainer ruled on at 00:1xZ — the ruling is the comment immediately above it, 5577119379, and it is not cited there. A card carrying a ruling comment is executed or contradicted with a reason, never re-presented (the standing rule from the wrongful re-flags of hotcrm#1342 / #1378 / objectui#7760; the mechanism is carded as objectstack#16662).

Answering the re-flag's open points from the ruling, so nothing here is new adjudication:

the re-flag asks	the ruling already says
一 / 二 / 三?	一 — the scheduled flow carries an organization id; 二 and 三 are out
"带哪个组织": flow declares one, or fan out per organization?	Flow declares one; no fan-out. Verbatim: 「多组织定时任务本来只能在组织内运行，应该带组织ID，不允许跨组织的定时任务」. A tenant wanting the sweep in N organizations declares it in N.
Is 三 inside the 2026-09-04 ADR-0131 pause?	Moot for this card — 三 was not chosen. (The seat's reading that it would be is reasonable and stays with #15207.)
Does the seat get to pick?	No, and it does not need to — the pick is made.

Two things in the re-flag are worth keeping and are consistent with the ruling: the observation that record-change flows carry an organization while schedule flows do not (the fix converges them), and the confidence gap about whether any deployment depends on scheduled runs not landing in sys_automation_run — the implementer checks that before landing consequence (2).

State: needs-user-decision → pm:queue, read back below. Dispatchable under the ruling's five consequences. ⛔ Not dispatched by the director seat.

---

Generated by Claude Code