Found at PM review of PR #9853 (#9851's reconciliation). Filed unassigned; observation class. Nothing is broken and no user is affected today — this records a gap in the cost record of an already-landed change, which became visible only once #9851 established that gate measurements are shape-dependent.
The gap
#9851 proved that runtime publish-gate cost tracks the tenant's authored object surface, not object count, and that PR #9825's cost table was measured against a stub-shaped seed (synthetic 5-field, expression-free objects). The correction of record is #4716 comment 5337939993.
#9825's object rows, now known to be stub-shaped:
| object write, schema-free (clean) | N=21 | N=420 |
|---|
| BEFORE (2-rule object door) | 0.21 ms | 3.65 ms |
| AFTER (7-rule object door) | 0.52 ms | 6.90 ms |
| published delta | +0.31 ms | +3.25 ms |
#9851 measured object writes on today's tree (post-#4716, object door = 7 rules), both shapes:
object write, today's main | N=21 | N=420 |
|---|
| stub shape | 0.39 ms | 8.15 ms |
| real shape (shipped showcase declarations) | 16.48 ms | 285.08 ms |
So the real:stub ratio for object writes is ~42× at N=21 and ~35× at N=420 — even steeper than the ~25× measured for flow writes, because the object door and the flow door run different rules.
What is missing: the real-shape BEFORE row. Nobody has measured the 2-rule object door against a realistic stack. Without it, #4716's cost delta on realistic object shapes is unknown. The +0.31 / +3.25 that the adjudication weighed describes a shape in which several of the newly-crossed rules have almost nothing to walk.
Why this is worth measuring rather than shrugging at
#4716's own body is emphatic about which path this is, and it is the reason P1 deliberately stopped at flow:
object 写入是产品里最热的元数据路径(Studio 每次改字段都走它),一个误判 422 的爆炸半径是租户唯一的编辑面
That argument was about false positives, but the same "hottest path, only editing surface" property applies to latency. The widening was approved against a cost table that we now know understates absolute object-write cost by ~35–42× at the shapes it reported.
Two of the five newly-crossed rules — validateRuleCompilability (#4762) and validateRuleSchemaFormats (#5178) — judge validation rules, which the stub shape carries none of. A third, lintAutonumberFormats, judges autonumber formats the stub also lacks. So there is a specific mechanism by which the measured delta would be shape-sensitive, not merely a general suspicion.
⛔ Do not manufacture the number
The delta cannot be recovered by scaling +3.25 ms by the 35× totals ratio. A ratio measured on totals does not transfer to a delta between two different rule sets, and the five new rules walk different keys than the two pre-existing ones. Producing a number that way would be precisely the error #9851 was raised to stop — and it would be worse than the original, because it would look like a measurement.
The honest present state is: unmeasured.
How to measure it — cheap, because the instrument now exists
scripts/bench/runtime-publish-gate.bench.mts (PR #9853) already does everything needed:
npx tsx scripts/bench/runtime-publish-gate.bench.mts --type object
It prints both shapes and the rules it dispatched. To get the BEFORE leg, build @objectstack/lint from the pre-widening registry (1408ae337^ for packages/lint/src/authoring-rules.ts, or revert the five runtimeTypes: ['object'] additions), confirm via the printed rule list that the object door reads 2 rules rather than 7, and run the same command. Use scripts/ablation-dist-preflight.mjs to prove the registry state is live in the built artifact before reading any number — an unbuilt dist silently reports the wrong registry, which is the hazard the bench's docblock calls out.
Report the delta with its shape named, per #9851's standing rule: a number quoted as "X ms at N objects" without its stack shape is not reproducible.
Also worth recording while there
285 ms per object publish at 420 real-shaped objects is a live figure for the product's hottest metadata write path, and it belongs in the perf record independently of the delta question. It is a sibling of #9613's flow-publish finding (461–485 ms at the same size), and the two may share a fix — see #9612 / #9613, both currently parked pending re-scope.
Priority
Low. Maintainer, verbatim, on this whole area: 「目前也没有相关的真实用户」, alongside the standing 「objectstack cloud 还没有正式上线,简化开发」. No tenant exists whose Studio saves this affects. File-and-measure when convenient; this is about keeping the record of a landed change honest, not about latency anyone is feeling.
Refs: #4716 (landed as PR #9825, squash 1408ae337; correction comment 5337939993) · #9851 / PR #9853 (the reconciliation and the instrument) · #9613 · #9612.
Found at PM review of PR #9853 (#9851's reconciliation). Filed unassigned; observation class. Nothing is broken and no user is affected today — this records a gap in the cost record of an already-landed change, which became visible only once #9851 established that gate measurements are shape-dependent.
The gap
#9851 proved that runtime publish-gate cost tracks the tenant's authored object surface, not object count, and that PR #9825's cost table was measured against a stub-shaped seed (synthetic 5-field, expression-free objects). The correction of record is #4716 comment
5337939993.#9825's object rows, now known to be stub-shaped:
#9851 measured object writes on today's tree (post-#4716, object door = 7 rules), both shapes:
mainSo the real:stub ratio for object writes is ~42× at N=21 and ~35× at N=420 — even steeper than the ~25× measured for flow writes, because the object door and the flow door run different rules.
What is missing: the real-shape BEFORE row. Nobody has measured the 2-rule object door against a realistic stack. Without it, #4716's cost delta on realistic object shapes is unknown. The
+0.31 / +3.25that the adjudication weighed describes a shape in which several of the newly-crossed rules have almost nothing to walk.Why this is worth measuring rather than shrugging at
#4716's own body is emphatic about which path this is, and it is the reason P1 deliberately stopped at
flow:That argument was about false positives, but the same "hottest path, only editing surface" property applies to latency. The widening was approved against a cost table that we now know understates absolute object-write cost by ~35–42× at the shapes it reported.
Two of the five newly-crossed rules —
validateRuleCompilability(#4762) andvalidateRuleSchemaFormats(#5178) — judge validation rules, which the stub shape carries none of. A third,lintAutonumberFormats, judges autonumber formats the stub also lacks. So there is a specific mechanism by which the measured delta would be shape-sensitive, not merely a general suspicion.⛔ Do not manufacture the number
The delta cannot be recovered by scaling
+3.25 msby the 35× totals ratio. A ratio measured on totals does not transfer to a delta between two different rule sets, and the five new rules walk different keys than the two pre-existing ones. Producing a number that way would be precisely the error #9851 was raised to stop — and it would be worse than the original, because it would look like a measurement.The honest present state is: unmeasured.
How to measure it — cheap, because the instrument now exists
scripts/bench/runtime-publish-gate.bench.mts(PR #9853) already does everything needed:It prints both shapes and the rules it dispatched. To get the BEFORE leg, build
@objectstack/lintfrom the pre-widening registry (1408ae337^forpackages/lint/src/authoring-rules.ts, or revert the fiveruntimeTypes: ['object']additions), confirm via the printed rule list that the object door reads 2 rules rather than 7, and run the same command. Usescripts/ablation-dist-preflight.mjsto prove the registry state is live in the built artifact before reading any number — an unbuiltdistsilently reports the wrong registry, which is the hazard the bench's docblock calls out.Report the delta with its shape named, per #9851's standing rule: a number quoted as "X ms at N objects" without its stack shape is not reproducible.
Also worth recording while there
285 msperobjectpublish at 420 real-shaped objects is a live figure for the product's hottest metadata write path, and it belongs in the perf record independently of the delta question. It is a sibling of #9613's flow-publish finding (461–485 ms at the same size), and the two may share a fix — see #9612 / #9613, both currently parked pending re-scope.Priority
Low. Maintainer, verbatim, on this whole area: 「目前也没有相关的真实用户」, alongside the standing 「objectstack cloud 还没有正式上线,简化开发」. No tenant exists whose Studio saves this affects. File-and-measure when convenient; this is about keeping the record of a landed change honest, not about latency anyone is feeling.
Refs: #4716 (landed as PR #9825, squash
1408ae337; correction comment5337939993) · #9851 / PR #9853 (the reconciliation and the instrument) · #9613 · #9612.