Uh oh!
There was an error while loading. Please reload this page.
refactor(spec)!: 「v17」摘除 connector.rateLimitConfig 出站限流词表 —— 执行引擎不存在 (#4911) - #4947
Merged
xuyushun441-sys merged 2 commits intoAug 3, 2026
Merged
Conversation
…te-limit shape (#4911) ADR-0049 enforce-or-remove: `ConnectorSchema.rateLimitConfig` declared an outbound throttle that no engine ever applied. The platform's only token bucket (runtime security/rate-limit.ts) is INBOUND; no connector provider reads the key and no seam exists that could. Removed rather than kept — the vocabulary returns with an implementation (#4834 / PR #4878 ruling). - `retiredKey()` tombstone on `ConnectorSchema.rateLimitConfig` (non-strict schema — a plain delete would be an ADR-0104 silent strip) - `ConnectorRateLimitConfigSchema`/`ConnectorRateLimitConfig` and the orphaned `RateLimitStrategySchema`/`RateLimitStrategy` removed with it - D2 conversion `connector-rate-limit-config-removed` (retiredFromLoadPath) + D3 chain step at major 17 - #4684's RENAMED_DEFS entry absorbed: rename-then-delete in the same unreleased major is a delete - baselines updated deliberately (manifest -2 defs, authorable -6 lines +2 [RETIRED], api-surface -4 exports); docs/spec-changes/upgrade guide regenerated Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Ehu85kbvMcrNTUJjwxvLJ9
…nector-ratelimit-retire
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
Contributor
📓 Docs Drift CheckThis PR changes 1 package(s): 106 hand-written doc(s) reference the affected code and may need an implementation-accuracy re-verification:
|
This was referenced Aug 3, 2026
xuyushun441-sys
marked this pull request as ready for review
August 3, 2026 17:48
Uh oh!
There was an error while loading. Please reload this page.
xuyushun441-sys
deleted the
claude/issue-4911-connector-ratelimit-retire
branch
August 3, 2026 17:59
xuyushun441-sys pushed a commit
that referenced
this pull request
Aug 3, 2026
Second serial sync. One conflict, the same `automation/` section as last time, and it arrived exactly as 批 10 predicted in the paragraph it left there. Resolution — both waves' rows kept, header and subtotal recomputed from the SURVIVING rows rather than resolved in favour of a side: surviving rows execution 13 · etl 10 · flow 1 · bpmn-interop 5 · node-executor 4 header 44 (HEAD) / 42 (main) -> 33 strip of 75 subtotal 18 (HEAD) / 16 (main) -> 7 authorable of 33 Both incoming numbers were right against their own branch and wrong against the merge: mine counted 批 10's deletions as still present, main's counted mine. That is the third instance in one day of the shape 批 10 wrote down — the header CONFLICTS and gets attention, while the subtotal line conflicts with nothing and merges clean while being wrong on both sides. The paragraph is rewritten as a per-wave table plus the rule stated mechanically, so the next batch does not have to rediscover it a fourth time. `check:strictness-ledger` arbitrates, and passes. Milestone worth noting in the ledger prose: with 批 9 + 批 10 + 批 11 merged, `automation/`'s authorable strip is **etl.zod.ts alone** (7 sites). The other 26 are wire — including `flow.zod.ts`'s last site `FlowVersionHistorySchema`, which is why that file still has a row while having 0 authorable left and must not be read as unfinished work. os-regen four-step ran in full. The driver deferred `authorable-surface.json` and `references/integration/connector.mdx` this time (recorded in os-regen-pending) rather than text-merging them. checkout origin/main for every `merge=os-regen` path -> install + rebuild spec -> `check:generated --fix` (regenerated `content/docs/references/**` only) -> assert BOTH waves survive: 批 10's control-flow/state-machine reference pages and its 21 TryCatch/Loop/StateNode/Transition authorable-surface entries coexist with this branch's `automation/Webhook:_packageId` / `:protection` and its two pages. The only deletions in the merged artifacts belong to main's own `connector.rateLimitConfig` retirement (#4911/#4947), not to either batch. Verification on the merged tree: check:generated 8/8 · all 8 pure audits PASS check:strictness-ledger: 42 open file(s) / 289 strip site(s) — counts match @objectstack/spec 297 files / 7474 tests · tsc --noEmit clean Part of #4001 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Ehu85kbvMcrNTUJjwxvLJ9
This was referenced Aug 3, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes#4911
父单 #4686 拆向之二(出站半边)。入站半边 #4910 文件面不相交,本 PR 未触碰
shared/http.zod.ts、api/endpoint.zod.ts、api/registry.zod.ts、system/http-server.zod.ts。为什么是「摘除」而不是「接执行」
不是「声明了没人读」,是声明了根本没有引擎——比前者更差一档。
全平台唯一的 token bucket 是
packages/runtime/src/security/rate-limit.ts,它是入站的:dispatcher 拿 request fingerprint 调consume(key),空桶就 429。出站方向没有任何对应物:四个 provider(connector-rest/connector-openapi/connector-mcp/connector-slack)都不读这个键,也没有可以接上去的缝。于是
strategy/maxRequests/windowSeconds/burstCapacity/respectUpstreamLimits/rateLimitHeaders六个旋钮:schema 校验通过、形状精确、作者相信自己已经把对第三方配额的调用速率封了顶——实际什么都没封。这正是 ADR-0049 存在的 false-compliance 类别。没有实现、也没有已承诺的 roadmap,experimental是没人许过的承诺,absent 才是诚实的处置。词表随未来实现一起回来(implementation-first,#4834 / PR #4878 同向裁决)。shared的RateLimitConfig顶替:那是入站限流器(enabled/windowMs/maxRequests),限的是别人打给我们的调用。#4684 正是为这个混淆才把两个名字拆开;conversion 刻意不做这个改写——那会静默改变行为,超出 D2 的无损范围。退役套件
ConnectorSchema.rateLimitConfig→retiredKey()墓碑(ConnectorSchema不是.strict(),直接删就是 ADR-0104 静默剥离)ConnectorRateLimitConfigSchema/ConnectorRateLimitConfig整体删除;孤儿枚举RateLimitStrategySchema/RateLimitStrategy随之删除(#3950:无消费者的导出 schema 会被下一个读到的人当成能力)connector-rate-limit-config-removed(retiredFromLoadPath: true,surfaceconnector.rateLimitConfig)MIGRATIONS_BY_MAJOR[17].conversionIds+ rationale 补段RENAMED_DEFS条目吸收:同一未发布 major 内 rename-then-delete 复合起来就是 delete可达性用 BFS 实证,不读散文
gen:schema的 def 遍历自己给出了答案——authorable-surface.json上两行同时变[RETIRED]:DeclarativeConnectorEntrySchema是ConnectorSchema.superRefine(…),从stack.zod.ts的connectors:可达,所以墓碑自动覆盖真作者面。测试里也直接跑了这条路径(见下)。路线自证:整 def 删除必须在四张 ratchet 上可见
按 skill 的对照表,「整 def 删除」必须看到变化(与「枚举值收窄」的零变化相反)。gen:schema 自己先开火,要求有意删除 manifest key:
删掉这两行后再跑,per-key ratchet 自行判定为 #4650 路径 3:
⛔ 基线没有手编:6 行是被门禁判定为合法删除后由
gen:schema整份规范化写出的。四张 ratchet 逐一自证(零意外新增)
json-schema.manifest.jsonintegration/ConnectorRateLimitConfig、integration/RateLimitStrategy✅authorable-surface.json[RETIRED]api-surface.jsonConnectorRateLimitConfig (type)/…Schema (const)/RateLimitStrategy (type)/…Schema (const)✅api-surface-signatures.jsondefineX参数,即引用z.input< typeof ConnectorSchema >,从不结构展开,所以 key 级收窄够不到它;被删的两个 def 也都不是 factory ✅strictness-ledger
integration/不在台账 triaged 目录内,实跑check:strictness-ledgerPASS 且无行要动——与立单预期一致。liveness 台账同理:connector不是 registry-rooted 的受治理 metadata type(packages/spec/liveness/下无connector.json),check:livenessPASS。pin 与 sabotage 实跑
pin 是符号身份断言(runtime 模块命名空间 + compiler-API),不是编译期
Assert< Equal< … > >——#4642 教训:spec 的tsconfig.json排除**/*.test.ts,编译期 pin 是空转文本。Sabotage 1(载荷最重的一条):只把 TYPE 加回来(
export type ConnectorRateLimitConfig = { maxRequests: number };)——类型被擦除,所有 runtimein检查照样绿:Sabotage 2:把键改回活的可选字段(静默剥离形状):
两次 sabotage 均已回滚,回滚后 295/7361 全绿。
验收扫描(三仓,带阳性对照)
"ConnectorRateLimitConfigSchema""ConnectorRateLimitConfig"rateLimitConfig(裸名)retryConfig在connector.zod.ts/authorable-surface.json均命中rateLimit10 命中、Connector5 文件——扫描器有效.changeset/bump-objectstack-*.md,引用 spec CHANGELOG 的散文)connectors7 命中、rateLimit3 命中——扫描器有效声明式判据(
^(export )?(const|type|interface)后接目标名 + 词边界)全部零命中。objectstack 侧残留全部属正常类别:墓碑处方、conversion 定义、pin 断言词、生成的迁移文档(spec-changes.json/protocol-upgrade-guide.md/ references)、[RETIRED]基线标记,以及历史 CHANGELOG / releases / 旧 changeset 的散文。裸名rateLimitConfig逐条核对无幸存家族子串误伤。门禁
check:*全跑(build 先于check:api-surface):check:generated8/8 up to date;八项 source audit(check:liveness/check:empty-state/check:variant-docs/check:strictness-ledger/check:skill-examples/check:exported-any/check:dual-source-exports/check:react-declaration-parity)全 PASSpnpm typecheck:122/122 successful@objectstack/spectest:295 files / 7363 tests passed(合并 origin/main 后复跑)@objectstack/clitest:67 files / 588 tests passed(含migrate-metae2e 重放)validate全部 exit 0pnpm check:i18nOK(9 包);check:doc-authoringOK;docs-auditscope OK未触碰
⛔
content/docs/releases/(未改一字);⛔ #4910 的入站文件面。.changeset/pre.json开工时已确认mode: pre/tag: rc,未改动。