Flow field expressions can call no function but `NOW()`/`TODAY()` — every other identifier is rewritten to `null`, so a computed money value can never be rounded to its field's declared `scale`

[os-sam]

Summary

The value-producing expression surface in flows — create_record.config.fields, update_record.config.fields, assignment.config.assignments — supports no function calls at all except the two hard-coded date tokens NOW() / TODAY(). Every other identifier is rewritten to the literal null before evaluation, so round(...), ROUND(...), Math.round(...), .toFixed(2) and Number(...) all silently evaluate to undefined.

Consequence: a flow cannot write a rounded value into a field that declares a scale. Any flow that multiplies a currency by a percentage produces a raw IEEE-754 double, which the (correctly) enforced field scale then refuses at insert time.

Measured on @objectstack/spec 17.1.0.

Where

packages/service-automation → src/builtin/template.ts, resolveToken(). After the NOW|TODAY regex and the $User. / bare-path branches, the fallback path does:

safe = safe.replace(/([A-Za-z_$][\w$]*(?:\.[A-Za-z_$][\w$]*)*)/g, (match) => {
 if (match === "true" || match === "false" || match === "null" || match === "undefined") return match;
 // ... resolve against flow variables ...
 if (val === void 0 || val === null) return "null"; // <-- every function name lands here
 ...
});
const fn = new Function(`"use strict"; return (${safe});`);

An identifier that is not a bound flow variable becomes null, so round(x, 2) compiles to null(x, 2), throws TypeError, and is swallowed by the surrounding catch { return void 0; }. The failure is silent — the field is simply written as undefined.

create_record and update_record both reach this via interpolate(cfg.fields ?? {}, variables, context); assignment reaches the same interpolate for its values.

Measured

Driving the real AutomationEngine + installBuiltinNodes (17.1.0) with amount = 180000, discount = 30:

raw => 125999.99999999999 (number) <- the unrounded product
ROUND(...) => undefined
round(...) => undefined
Math.round(...)=> undefined
(...).toFixed(2) => undefined
Number((...).toFixed(2)) => undefined

Only pure operator arithmetic evaluates, because operators need no identifier:

(x * 100 + 0.5 | 0) / 100 => 126000
(x * 100 + 0.5 - ((x * 100 + 0.5) % 1)) / 100 => 126000

Neither is an acceptable authoring pattern: the | 0 form is an int32 coercion that silently overflows above ~21.5M (any amount over 2147483647 / 100), and the % form has to repeat the entire product three times inside one expression.

The asymmetry

The platform already has a rounding primitive. @objectstack/formula's CEL stdlib exports 35 functions including round, floor, ceil, abs, min, max:

now, today, daysFromNow, daysAgo, daysBetween, addDays, addMonths, date, datetime,
abs, round, floor, ceil, min, max, upper, lower, trim, contains, startsWith, endsWith,
matches, joinNonEmpty, isBlank, isEmpty, coalesce, len, size, has, int, string, bool,
double, timestamp, duration

But service-automation imports ExpressionEngine for exactly one call site — evaluateCondition() — and coerces its result with Boolean(result.value). So CEL is wired in as a predicate surface only (edge conditions, decision conditions, start gates). The value-producing surfaces run the separate bespoke new Function mini-evaluator above, which has no function vocabulary.

The result is that the same flow file can call round() in an edge condition and cannot call it in a field value.

Why this matters

scale enforcement on number/currency fields is correct and landed deliberately (#7501). With it enforced and no rounding reachable from the expression surface, any flow computing money from a percentage is unshippable — the write is refused at insert time and the flow node fails.

Standing example, found by driving the flagship exemplar app in a browser: objectstack-ai/hotcrm#1206 — Generate Quote fails for most non-zero discounts because the flow hands 180000 * (1 - 30/100) = 125999.99999999999 to two scale: 2 currency fields. That card is blocked on this gap; there is no app-side fix that is not a workaround for a missing platform primitive.

Suggested direction (not ruled)

Options, roughly in increasing order of scope:

1. Extend the template evaluator's known-function table beyond NOW/TODAY with a small numeric set (round, floor, ceil, abs, min, max). Smallest change, but grows a second, divergent function vocabulary next to CEL's.
2. Route value-producing expressions through the CEL ExpressionEngine that already backs conditions, so one dialect and one stdlib serve both predicate and value positions. Larger, and needs a compatibility story for the {var} template dialect the existing flows use.
3. Coerce on write — have the data layer round to the declared scale instead of refusing. Rejected on its face here for surfacing: silent coercion of money is worse than a loud refusal, and it would undo A number field's declared scale is never enforced — values with more decimals are accepted and stored verbatim (min/max on the same field are enforced) #7501's intent.

Option 2 looks right for "declared = enforced, one dialect", but the migration surface is the real cost and this needs a ruling rather than an agent's pick.

[os-zhuang]

Triage: routed domain:services(落点 packages/service-automation),type Feature,入决策箱 needs-user-decision —— 扩大表达式面的接受集 = 功能新增/契约形状,人工地板,⛔ 不派发。落卡即带四维分析(业务视角):

一句话问题:流程(Flow)给字段赋值时连 round() 都调不了 —— 算个打折价都会因为小数位超标被拒绝写入,旗舰示例应用的「生成报价单」在大多数折扣下直接失败(hotcrm#1206),而且失败是静默的(函数名被改写成 null,字段悄悄变 undefined)。

选项(客户可感知代价):

• A — 给模板求值器补一张小函数表(round/floor/ceil/abs/min/max):改动最小、最快解封报价单;代价是平台从此有两套函数词汇 —— 条件位一套(CEL 35 个函数)、赋值位另一套(6 个),客户要记住「同一个 flow 文件里,这行能用的函数下一行不能用」。
• B — 赋值表达式统一走 CEL 引擎(条件位已在用):一种方言、一套函数、declared=enforced;代价是要给存量 {var} 模板方言做兼容,迁移面未测量,工期显著大于 A。
• C — 写入时按 scale 静默四舍五入:不修表达式面;代价是钱被平台悄悄改数,比响亮拒绝更糟,且推翻 A number field's declared scale is never enforced — values with more decimals are accepted and stored verbatim (min/max on the same field are enforced) #7501 的本意。荐直接排除。

四轴:

• 实际业务需求:真实拉动,非投机 —— 旗舰 CRM 的报价流程今天就写不出来,「金额 × 折扣率」是任何业务应用的第一等场景。
• 项目长远合理性:B 是唯一符合 contract-first 的终态(一种方言);A 是临时补丁,长期代价 = 第二套词汇永久分叉,且日后仍要还 B 的债。
• 防 AI 写代码犯错:现状是最坏形态(函数名静默变 null);A 之后 AI 仍会在赋值位写出条件位学来的 CEL 函数然后静默失败;B 让「在哪学的就在哪用」结构性成立。
• 创业阶段不扩散需求:A 最克制(6 个函数,全部镜像 CEL 现有名字,不发明新语义);B 的迁移面是真实成本,现在做可能挤占核心能力。

推荐:A 先行解封(函数名与语义逐一镜像 CEL,⛔ 不发明第二套语义),同笔立一张 B 的后续卡挂 pm:on-hold + Restart-when: 待维护者定 appetite —— 四轴在 A/B 间真实分裂(长远指 B、聚焦指 A),如实上交。回退:若裁 B 直做,A 作废零沉没。低摩擦裁决:回「A」/「A+B后续」/「B」/「C」即可。

本分析看不见什么:存量 flow 对 {var} 模板方言的依赖面(B 的真实迁移成本)未测量;A 的六函数集是否覆盖真实需求分布(除 round 外其余五个是推断)未验证。

[facets-block]

• 业务需求:A/B 同向 —— 报价流程今天不可用,真实拉动
• 长远合理:指向 B —— 一种方言一套函数,A 是分叉
• 防 AI 错:指向 B —— 静默 null 改写是最坏形态,A 只缓解一半
• 阶段聚焦:指向 A —— 六函数镜像 CEL,最小解封
  推荐:A(+B 后续卡待 appetite)· 置信缺口:{var} 方言迁移面未测量

---

Generated by Claude Code

[os-zhuang]

Maintainer ruling recorded (2026-08-23, live PM chat, verbatim: 「其他同意你的意见」— adopting recommendation A + B-follow-up): A lands now — the flow field-expression evaluator gains the small function table (round/floor/ceil/abs/min/max), every name and semantic mirrored 1:1 from the CEL set, ⛔ no second semantics invented. Option C (silent rounding of money) is rejected outright. The unification question (B — assignment expressions move onto the CEL engine) is deferred to a follow-up card the triage seat files in the same stroke, on hold until the maintainer sets appetite (revisit fires when this card closes).

State: needs-user-decision → pm:queue, domain:services (same stroke). Dispatch constraints: Clause-② yes (expands the accepted expression vocabulary — contract-review tier); the silent-null rewrite of unknown identifiers must become a LOUD authoring-time diagnostic in the same PR for the six supported names' misuse cases (unknown function ⇒ named error, not null); oracle = the hotcrm quote-flow repro (hotcrm#1206): a discount write within declared scale must succeed end-to-end.

---

Generated by Claude Code