观察类发现,实施 #4923(PR #5731)时顺手清点,未修、不在该单范围内。今天没有用户会撞到,故只记录不排期。
事实
#4923 的维护者裁决把 renameKey / renameConfigKey 遇「两个拼法同时存在」的处置改成按值拆分:等值删冗余 + 发 notice,异值双保留交给 strict 门点名双键。liftNotifySourceShape 按 issue 点名一并跟进。
conversions/registry.ts 里还有两处结构不同、但同样以「规范/声明的一侧赢,另一侧原样遮蔽」收场的分支,它们没有跟着动,而且是刻意的:
| 位置 |
形状 |
当前分支 |
liftWaitEventConfig(WAIT_EVENT_CONFIG_LIFTS) |
松散 config.duration 等 → 声明块 waitEventConfig.timerDuration |
waitEventConfig 已有值则不抬,松散键原样留下 |
connector_action 的声明块 lift |
config.connectorId → connectorConfig.connectorId |
cc[key] != null 则 continue,松散键原样留下 |
PR #5731 在 liftWaitEventConfig 的注释里写明了为什么不扩张,并在 conversions.test.ts 对应用例上留了同样的说明,免得下一个读者以为是漏改。
为什么它和 #4923 不是同一个问题
所以按 #4923 的口径直接套过来是不成立的,需要单独判一次。
待裁定的问题(若认为值得动)
- 松散候选与声明块的值结构相等时,是否也按无损卫生删掉松散键 + 发 notice?
- 多候选情形下,等值比较的对象是「声明块的现值」还是「第一个 present 的候选」?被判定等值的候选是删一个还是删全部?
- 不等时保留松散键——这一半已经是现状,strict 契约也已按此拒绝,应该无需变更。
现状为何不算缺陷
松散键留下后由收紧后的 wait / connector_action 契约拒绝,并带处方;也就是说最终结果是响的、可行动的,只是元数据在静止态没被清干净(和 #4923 修掉的那一半同源的卫生问题,程度更轻)。没有「今天能跑、17 上硬停」的可达回归——那正是 #4923 之所以要修的理由,而这两处不具备。
相关
观察类发现,实施 #4923(PR #5731)时顺手清点,未修、不在该单范围内。今天没有用户会撞到,故只记录不排期。
事实
#4923 的维护者裁决把
renameKey/renameConfigKey遇「两个拼法同时存在」的处置改成按值拆分:等值删冗余 + 发 notice,异值双保留交给 strict 门点名双键。liftNotifySourceShape按 issue 点名一并跟进。conversions/registry.ts里还有两处结构不同、但同样以「规范/声明的一侧赢,另一侧原样遮蔽」收场的分支,它们没有跟着动,而且是刻意的:liftWaitEventConfig(WAIT_EVENT_CONFIG_LIFTS)config.duration等 → 声明块waitEventConfig.timerDurationwaitEventConfig已有值则不抬,松散键原样留下connector_action的声明块 liftconfig.connectorId→connectorConfig.connectorIdcc[key] != null则continue,松散键原样留下PR #5731 在
liftWaitEventConfig的注释里写明了为什么不扩张,并在conversions.test.ts对应用例上留了同样的说明,免得下一个读者以为是漏改。为什么它和 #4923 不是同一个问题
objectvsobjectName),两边是同级的、1:1 的;config这个位置本身才是退役的东西,而且WAIT_EVENT_CONFIG_LIFTS是一个 target 对多个候选名(timerDuration的候选有duration等),「等值就删」在多候选下要先定义「和谁比、删几个」。所以按 #4923 的口径直接套过来是不成立的,需要单独判一次。
待裁定的问题(若认为值得动)
现状为何不算缺陷
松散键留下后由收紧后的
wait/connector_action契约拒绝,并带处方;也就是说最终结果是响的、可行动的,只是元数据在静止态没被清干净(和 #4923 修掉的那一半同源的卫生问题,程度更轻)。没有「今天能跑、17 上硬停」的可达回归——那正是 #4923 之所以要修的理由,而这两处不具备。相关