发现于 #5515(修同文件 L3 sapConnector 示例的四处键名/取值)时,属于同一节的散文而非示例块,不在该 PR 的裁定范围内。
事实
packages/spec/src/integration/connector.zod.ts:685 起,rateLimitConfig 是一个 retiredKey() 墓碑:
'`connector.rateLimitConfig` was removed in @objectstack/spec 17.0.0 (#4911, ADR-0049 D2) —
the entire shape is gone, not just this key: `ConnectorRateLimitConfig` and its
`RateLimitStrategy` enum were removed with it, because no outbound rate-limiting engine
ever existed …'
同文件 317–340 行的长注释写得更明白:平台唯一的令牌桶是 packages/runtime/src/security/rate-limit.ts,而它是入站的;没有任何东西节流我们发出的调用。
而 packages/spec/docs/SYNC_ARCHITECTURE.md 的 L3 段仍有三处反过来讲:
### Key Features 列表:- ✅ **Rate Limiting**: Token bucket, leaky bucket algorithms —— 打了勾,还点名了两个从来不存在的算法。## Decision Matrix 表:| Do you need rate limiting and retry policies? | **Yes** → L3 (Connector) | —— 一半是对的(retryConfig 真在),一半把作者引向一个已退役的键。#### Pattern 2: Enterprise Integration (L3) 的示意图:Webhooks, Auth, Rate Limiting。
示例块里那行 // (rateLimitConfig 曾在这里,#4911 退役) 的墓碑注释是对的 —— 恰恰是它证明文档的其余部分没跟着改。
影响
Prime Directive #10 的正面反例:一个作者读 Key Features 打勾的那行,去写 rateLimitConfig,拿到的是 strictObject 的退役提示。比编译不过更糟的是,他会以为"平台会替我限流"这件事成立 —— 这是 #4911 的注释专门点名的那种"最像安全承诺的一面"。
建议
三处都改成如实说法:出站限流请在 provider / 网关侧做(#4911 的墓碑文案已经有现成措辞),retryConfig 与 health.circuitBreaker(ConnectorHealthSchema:512,真实存在)保留。属纯文档修正,但涉及三处措辞选择,值得单独一单而不是搭 #5515 的车。
Blocked-by: #5515
发现于 #5515(修同文件 L3
sapConnector示例的四处键名/取值)时,属于同一节的散文而非示例块,不在该 PR 的裁定范围内。事实
packages/spec/src/integration/connector.zod.ts:685起,rateLimitConfig是一个retiredKey()墓碑:同文件 317–340 行的长注释写得更明白:平台唯一的令牌桶是
packages/runtime/src/security/rate-limit.ts,而它是入站的;没有任何东西节流我们发出的调用。而
packages/spec/docs/SYNC_ARCHITECTURE.md的 L3 段仍有三处反过来讲:### Key Features列表:- ✅ **Rate Limiting**: Token bucket, leaky bucket algorithms—— 打了勾,还点名了两个从来不存在的算法。## Decision Matrix表:| Do you need rate limiting and retry policies? | **Yes** → L3 (Connector) |—— 一半是对的(retryConfig真在),一半把作者引向一个已退役的键。#### Pattern 2: Enterprise Integration (L3)的示意图:Webhooks, Auth, Rate Limiting。示例块里那行
// (rateLimitConfig 曾在这里,#4911 退役)的墓碑注释是对的 —— 恰恰是它证明文档的其余部分没跟着改。影响
Prime Directive #10 的正面反例:一个作者读 Key Features 打勾的那行,去写
rateLimitConfig,拿到的是strictObject的退役提示。比编译不过更糟的是,他会以为"平台会替我限流"这件事成立 —— 这是 #4911 的注释专门点名的那种"最像安全承诺的一面"。建议
三处都改成如实说法:出站限流请在 provider / 网关侧做(#4911 的墓碑文案已经有现成措辞),
retryConfig与health.circuitBreaker(ConnectorHealthSchema:512,真实存在)保留。属纯文档修正,但涉及三处措辞选择,值得单独一单而不是搭 #5515 的车。Blocked-by: #5515