Repository navigation
release v0.1.176 - #1783
release v0.1.176#1783
Conversation
[bot] 🏷 收到 release v0.1.176 fallback PR。这是 one-click release 被 branch protection 挡下后的自动兜底 PR(正文含 |
📦 Built Package ArtifactBranch: Option A — Install this exact build (recommended)npm install -g billion-context@0.0.1761-pr.1783.c0e39acThis exact version is immutable and reproducible. The rolling Option B — Download artifact
tar xzf billion-context-pr1783.tgz
npm install -g packageInstall instructions are refreshed on each push. |
|
有新进来两个pr 注意 |
[bot] 🏷 收到,已看这两个新 PR:
与 release PR #1783 的关系:两者都基于当前 master,#1783 的 diff 只有 package.json/lock 的版本行,无文本冲突。顺序上两种都行——先合 #1783,则 #1779/#1780 进下一个版本(v0.1.177);若要把这两个塞进 v0.1.176,需要先把它们合入 master 再让 fallback 流程更新 release 分支(它已经自动 merge 过一次 master 到 e95f3c6)。默认建议:#1783 按现状合出 v0.1.176,两个新 PR 随后走正常流程。是否要等它们进本版本由你拍板。 继续做 v0.1.175→v0.1.176 区间回归审计,结论稍后补。 |
[bot] 🏷 一句话摘要:纯版本号 release PR(0.1.175→0.1.176,diff 仅 package.json/package-lock.json);已对 v0.1.175..最终 head 结构化七问1. 是什么问题 2. 什么原因导致的(针对唯一的 CI 红)
3. 怎么修复的 4. 是否有回归问题 5. 是否破坏缓存 6. 是否改了设计方向 7. 是否引入了新的配置 重大行为变更清单(old→new+原因)
机械核查(全过)
CI 状态 @44f477348/9 绿;唯一红 = 判定可合:内容层面零回归、本地全绿、机械核查全过;合并前确认 windows job 重跑转绿即可(若合并前 master 再前进导致 head 移动,只需对增量做差异复审,机制同上)。我不会代合并——请你在 #1783 操作。 |
[bot] 🏷 跟进:已触发的 至此 head |
|
应该又进来许多 审查了吗 |
…g-guard fix(dsh): stale verifyAttachAndRecover landings must never clobber the self-healed register (#1783)
…e self-healed register windows-22 CI on the v0.1.176 release PR (ranxianglei#1783) deadlocked the ranxianglei#983 self-heal test: the apply() attach chain resolves long after it started (loopback probe + evidence grace + process spawn are all slow there), and in the meantime maybeRetry can already have healed the register onto a new origin — the late landing then wiped register.base/toolsReady unconditionally, or registerTools' catch armed a global 10s retryAt against a base the register had already moved past, freezing every later heal attempt behind the wall. Three changes, one contract: a landing may only write the register while it still owns it (base undefined, or still the stale origin the chain set out to replace): - landingOwnsRegister() guards both wipe sites and the fallback origin reset in verifyAttachAndRecover - the unfreeze wipe also clears retryAt — a back-off armed against the stale base dies with it - registerTools scopes its back-off to the base that actually failed Two deterministic regression tests pin the interleavings (slow preset probe; slow spawn seam) — both fail on master, pass with the fix.
A re-activation after a HEALTHY registration used to leave the bili tools dead until dsh restarted — the same #2082 symptom reached from the success ordering. apply() reset register.dead and activeCtx, but not register.toolsReady: the tools registered into the deactivated context die with it, while every registerTools()/maybeRetry() early-returns on the stale stamp, so the new context never re-registers (and headersFor keeps stamping plugin mode for a lane whose dsh side has no tools). Clear toolsReady (and retryAt, per #1783's fresh-activation rule) when apply() sees a context change. Scoped to a context CHANGE: a same-context re-apply keeps its registration (the attach verify path already re-checks on its own). tests/issue2101-dsh-reactivation.test.ts: the success-ordering re-activation test times out on the unfixed tree (verified) and passes with the clear; a same-context re-apply stays healthy.
…n commits Round-2 CI (u24s1) timed out '#983 maybeRetry self-heals a base-less register after a failed respawn' (15s waitFor). The giveUp generation guard was also applied to the spawnFallback landing, but a fresh-spawn landing is live by construction — it cannot resurrect anything — and the self-heal contract (#983/#1783) requires exactly these late landings to re-base a given-up register. A giveUp that lands between fallback start and landing must not suppress the heal. The guard now covers only verifyAttachAndRecover's three commits of an EXISTING origin (equal/newer branch, rotation-refusal branch, pinned-recovery branch), whose liveness was probed earlier and may be stale at commit time — the exact #3380 resurrection hazard, proven by the measured incident-test timeline (giveUp T589.23 < refusal commit T592.18). Local: dsh-native.test.ts 55/55, #983 self-heal 20x stable, issue3380 6/6, issue3544 16/16, native-intercept 62/62, launcher 313/313, typecheck clean.
Auto-fallback from the one-click release workflow: direct push to master was blocked by branch protection. Merging this PR publishes via the standard release.yml flow.
Changes since v0.1.175
dshnot resolvable on PATH — profile copy stays frozen (#1196 contract) #1732): keep GBK decoding effective on the async refresh pathdshnot resolvable on PATH — profile copy stays frozen (#1196 contract) #1732): platform-aware spawn assertion — win32 .cmd shims go through comspec ([bug] Windows: a space in the client or -e path truncates the launch (spawn shell:true, unquoted) — and silently kills compression when only the command is quoted #679)dshnot resolvable on PATH — profile copy stays frozen (#1196 contract) #1732): resolve dsh binary beyond bare PATH name; decode GBK subprocess output