feat(service-automation): a record-triggered flow's notification links to the record that started the run when it names no link - #30252

Requested by Bill · project thread

domain:server#4 · os-bill · session_01Utp6CZMkHvuDeVYgTD73qF

维护者速读

• 改了什么： 由记录触发的流程里，通知节点没写 sourceObject/sourceId/actionUrl 时，通知默认链到触发这次运行的那条记录；点开通知直接进记录页。
• 为什么改： 技术员收到「工单分配给你」的通知，点开却落在通知列表；作者照最自然的写法（收件人、标题、正文）写，os validate 也通过，链接却是空的。卡 Flow notify: a record-triggered flow's notification links nowhere unless the author adds the source pair #30121「第一组：会卡住人或误导人」。
• 风险与回滚： 只在三项都没写、且运行确有触发记录时生效；显式的一对或 actionUrl 照旧优先，半对照旧丢弃，定时/API/无记录的手动运行不变，删除事件不链（记录已不在）。回滚即撤本 PR。
• 先看： packages/services/service-automation/src/builtin/notify-node.ts 的 defaultClickThroughOf 与调用处，再看 notify-node.test.ts 末尾新的 describe。
• 两分钟验证： pnpm --filter @objectstack/service-automation exec vitest run --maxWorkers=2 src/builtin/notify-node.test.ts，预期 23 条全绿。
• 需要你做的： 无，席位落地。

Fixes #30121

Clause-②: no — no accepted key, value or exported type changes; sourceObject / sourceId / actionUrl keep their meaning when written, and no option or type member was added to reach the trigger record (the node already reads it through triggerRecordOf).
Metadata-protocol: semantic
Skills-docs: follow-up owed — skills/objectstack-automation/SKILL.md (the notify example's click-through: a PAIR, else dropped line), content/docs/automation/flows.mdx (the notify sourceId paragraph), packages/spec/src/automation/io-node-config.zod.ts (the sourceObject / sourceId describes, which feed content/docs/references/automation/io-node-config.mdx). The skill line is a governed (Tier H) edit and the spec describe is out of this order's scope, so neither rides here; the seat files the card.

What changes

@objectstack/service-automation — the notify node (src/builtin/notify-node.ts):

• New defaultClickThroughOf(cfg, context, trigger). When the node writes none of sourceObject, sourceId and actionUrl, the click-through record is the run's trigger record, read through the existing triggerRecordOf(context): the same reading recipients: { emailField } and the organization fallback already use. The messaging service then stores it as sys_notification.source_object / source_id and synthesizes /OBJECT/ID, exactly as for an authored pair.
• What counts as a trigger record, measured on origin/main at the run-starting doors:
  • record change (trigger-record-change): object + the row, record.id present. Defaults.
  • time-relative sweep (trigger-schedule time-relative-trigger.ts): object: desc.object, record: row. That object's row is the record the run is about, so it defaults.
  • action on a record (runtime action-execution.ts): object + record with the requested recordId stamped. Defaults.
  • schedule tick, inbound API post (trigger-api: record: payload with no object), manual REST start (object but no record): no trigger record. Unchanged.
• Delete events (beforeDelete, afterDelete) are not defaulted: the record is gone once the write lands, and this node already drops a half-written pair so the inbox never renders a dead link. An authored pair on a delete flow is still honoured.
• A half-written pair keeps today's behaviour: it is dropped and nothing is defaulted in its place, because the author did write a link.
• An actionUrl written alone keeps today's behaviour too: the URL is the link and no source is defaulted beside it, per the card's "an explicit actionUrl or pair still wins".
• The organization fallback (Notifications emitted from a system-context run (schedule tick, approval node) are stored with organization_id NULL on 18.0.0-next.0: the platform's own WARN says reports and cleanup that filter by organization will not see them #23284) asked [source, trigger]; a defaulted source is the trigger record itself, so the second candidate is skipped when it is the same object (no second findOne). The organization it resolves is unchanged.
• The Studio form help for sourceObject, sourceId and actionUrl (the node descriptor's configSchema) says the default.

Tests

src/builtin/notify-node.test.ts, one new top-level describe in the existing harness, six pins:

1. record-triggered notify, no link written ⇒ source is { object: 'repair_ticket', id: 't_7' }, no url;
2. explicit pair wins over the trigger record;
3. explicit actionUrl alone: url as written, no source defaulted;
4. half-written pair (sourceObject only): still dropped;
5. run with no trigger record (object, no record): no source;
6. afterDelete: no source.

Acceptance notes

• The spec's own describes for sourceObject / sourceId (packages/spec/src/automation/io-node-config.zod.ts) still say "Only takes effect together with …", which stays true for an authored pair but does not mention the default. Out of this order's scope (packages/spec/src/**); listed under Skills-docs: above.
• A flow started by an action whose caller could not read the row (recordLoadDenied: true) still carries the requested id, so its notification links to that id, as the authored sourceId: record.id would. The record page applies the recipient's own access when opened.

Verification

Gate list derived with node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack; each command's exit code was recorded before any pipe and reconciled with --ran. Readings are in the os-dev-report comment on #30121. origin/main was merged once before opening (no incoming commit touched service-automation or packages/spec).

Generated by Claude Code