Repository navigation
Conversation
…while the parent is still active livePersonaDescendant picked a follow target by freshness alone (fork.lastSeen > parent.lastSeen). A parallel persona fork / subagent lane sharing the base id with a still-active parent looks exactly like a frozen parent case, so host-stamped management calls (compress/decompress/ acp_status) got redirected into the fork's ref namespace and failed "every ref is unknown to this session" / cannot-anchor - 8 consecutive failures in a dsh fusion-board session. Gate the follow on birth order: follow a fork only when the parent saw NO traffic after the fork was minted (fork.createdAt > parent.lastSeen). A parent still receiving turns stays authoritative; its refs live in its own namespace. ranxianglei#2601 legit shape (frozen parent -> fork continuation) and the switch-back self-heal are preserved. Regression: tests/persona-fork-active-parent-guard.test.ts - frozen-parent still follows the fork; active-parent does not redirect. issue2601 / issue2948 suites stay green. See ranxianglei#3647.
ranxianglei
changed the title
(ai: vllm-qwen/qwen3.8-27b) 查重: 不重复。 与在途 PR #3405(「persona conversation keys survive proxy restarts; management calls follow the fork holding cited refs」#3397)同属「persona lineage follow 误路由」家族但机制不同:#3405 回答「跟哪个 fork」(候选内 cited-ref frontier 优先),本 PR 回答「该不该跟」(birth-order 门禁:frozen parent 才跟)。上游关联 #2601(follow 规则本源)、#2948(holdsRefs 守卫)均已合入且与本改动正交。open+closed 检索无其他条目覆盖 active-parent 形状。 方向关(独立复核,不照抄 issue 结论):
中间状态:CI(head |
(ai: vllm-qwen/qwen3.8-27b) PR 审核结论(独立审核,非复读 issue): ① 方向关:读原 issue #3647 + 独立推演后确认方向正确。根因在选择准则本身—— ② 回归关(逐项清点既有行为,全部本地实测):
③ 代码关:单行谓词替换 + 注释块重写。注释准确解释了 why(出生顺序 vs 新鲜度、事故引用),符合本文件惯例。 ④ 测试有效性关:断言有牙且已做红绿双向验证——
⑤ diff 整洁度:单 commit 落在当前 master tip 上(无陈旧 base),3 文件。一个 nit: 八问:
证据汇总:本地定向运行——新测试绿;红检(还原旧谓词→case 2 红→恢复→绿);issue2601 7/7;issue2948 2/2;typecheck 干净。远程 CI:ubuntu-22×3 shards + static-gates 已绿,ubuntu-24/windows 运行中; 判定:质量达标,可合(等 CI 全绿后由人工合并——agent 无合并权限,PR 链接:https://github.com/ranxianglei/billion-context/pull/3648)。 |
(ai: vllm-qwen/qwen3.8-27b) 审核结论 — 结构化八问
验证证据
行为变更披露(旧→新)
代码质量(外部提交硬标准)逐项通过:注释讲清 discriminator 与事故出处且与代码事实一致;无死代码/魔法数字(复用既有常量);测试断言有牙(part 2 精确复现事故形状);diff 收敛到目的。一处小点: 协同与排序#3405 当前对 master 为 dirty( 判定:可合(合并由人执行)。 |
Resolve the livePersonaDescendant conflict by composing both changes: master's ranxianglei#3397 ref-frontier preference now picks among candidates gated by the ranxianglei#3647/ranxianglei#3648 birth-order rule (fork.createdAt > parent.lastSeen). An active parent empties the candidate set, so neither the recency fallback nor the no-fit fallback can land on a parallel fork; a frozen parent keeps ranxianglei#2601 follow with ref-fit preference. .gitignore takes the union of both sides.
(ai: vllm-qwen/qwen3.8-27b) 冲突已解决,PR 恢复可合并。说明: 原因:你开 PR 后 master 前进了——#3405 已合并并随 v0.1.204 发布,它重写了 解法(组合,非二选一):我把
证据(合并头本地定向验证): 新 head: |
Fixes #3647
Problem
The
#2601persona-lineage follow (livePersonaDescendant) redirected a host-stamped nativeCaller management call (compress / decompress / acp_status) into a|sub:persona fork whenever the fork was fresher than the raw parent:ts return personaDescendantsOf(parent.id).find((s) => (s.lastSeen ?? 0) > (parent.lastSeen ?? 0));That recency rule also matches the active-parent shape: the parent kept receiving turns after the fork was minted (parallel persona forks, or subagent lanes sharing the base id), and the fork happens to be the fresher one. Re-routing the host's call into the fork's namespace then fails with "every ref is unknown to this session" / cannot-anchor — the same breaker
#2601exists to cure, reproduced in reverse. Field incident: a dsh (DeepSeek Harness) session under fusion-board subagent traffic suffered 11 consecutive compress failures, 8 of them cannot-anchor, all behind thefollowing live fork …(#2601)redirect log, with the fork refs counter oscillating (three parallel forks sharing the base id).#2948(ref-less aux lanes) and#3405(follow the fork holding the cited refs) are complementary and do not cover this: both still pick a fork when the parent is live, because neither consults whether the parent saw traffic after the fork was born.Root cause
lastSeenonly says which session is freshest; it cannot distinguish a frozen parent (the#2601legit shape — the fork is the continuation, the host's refs can only live in the fork) from a still-active parent (the incident shape — the parent's refs live in its own namespace; redirecting them into a fork is wrong).Fix
Gate the follow on birth order, not freshness.
Session.createdAtis stamped at session mint time (src/session.tscreateSession); the fork is minted when the persona split happens. Follow the fork only when the parent saw no traffic after the fork was born:ts return personaDescendantsOf(parent.id).find((s) => (s.createdAt ?? 0) > (parent.lastSeen ?? 0));#2601):fork.createdAt > parent.lastSeen→ still follows the fork. No regression.parent.lastSeenlands afterfork.createdAt→ parent stays authoritative, no redirect.lastSeenadvances past every fork'screatedAt→ no follow.Complementary with
#3405: that PR decides which fork to follow when a follow happens (by refs ownership); this change decides whether a follow happens at all (the parent must be frozen). Both can land independently.Tests
New
tests/persona-fork-active-parent-guard.test.ts:#2601).|sub:.Existing
issue2601-persona-fork-lineage(6 unit + 1 e2e) andissue2948-aux-lane-lineage-guard(2 e2e) suites pass unchanged. Typecheck clean.