Follow-up to #4807: live hot-path evidence correlated with our current locally patched rc.2 profile

[yangfei222666-9]

Context: in discussion #4807 we reported synchronous giant-session restore/event-loop stalls and four linear-scan sites. Since then we sampled the live desktop-managed dsh web process again. This adds live-process evidence correlated with the current local post-fix resolver/disk state; we did not inspect the process's ESM module cache.

Method

• Live process: desktop-managed dsh web, listener 127.0.0.1:3080 (PID/PPID/PGID frozen, launched 2026-08-28 07:24:28 +0800).
• macOS /usr/bin/sample on the live PID, 5s rounds (three rounds), plus a 1s top series in the same window.

Findings

1. Intermittent, not sustained. Two earlier samples had ArraySome frames account for 80.6% / 96.9% of main-thread samples, with native frames along HTTP → V8 → Builtins_ArraySome / Builtins_ArraySomeLoopContinuation → Runtime_GetProperty / LookupIterator → FastPackedFrozenObjectElementsAccessor. Three later 5s rounds caught the same signature in only one round (2.3%), while the others were mainly parked in kevent. A 1s top series in the same window showed 46.1% → 99.8% → 99.1% → 100.9%. So this was a pulsing hot loop in the sampled window, not a permanent peg.
2. Disk/resolver evidence points to the post-fix series. The profile resolver points at the profile dsh-host-apiproxy/lib/index.js (SHA-256 a7ea5a8b…), and global/profile copies are byte-identical. This evidence strongly disfavors the old 7f9… series, but is not in-process module-cache proof.
3. Highest-match residual source candidate: in the current local host package, the only direct session.events.some(...) call site we identified is agentPreset.select's blank check; on a miss it can scan the full frozen log. The client source contains a staged-preset path that can reach this check. The native sample did not identify the endpoint.
4. A separate send-latency candidate: warm-projection miss lifecycle. The restore seed emits no session/event; peekStateOf does not lazily build; and session/created is published before the first live event. A freshly restored session therefore misses at session/created until an explicit build or the first live event creates the cell. If the cell is still missing, that first event may trigger a synchronous prefix fold over the log, which we suspect could contribute to send latency; this is distinct from the Array.some pulse above.

Our candidate fix (designed, not yet applied — happy to share a patch draft)

For the preset-select blank check: read a warm snapshot with a current watermark when available; on miss, use a bounded async blank resolver (eventAt/seq + WeakMap prefix cache + 8ms / 1024-event yields + in-flight dedupe). Explicitly avoid a stateOf() miss fallback, which would relocate the synchronous full fold.

Boundaries

• Native samples do not name the JS function or the RPC endpoint — attribution above is source-level highest-match, not a unique root cause.
• We have not proven that this pulse causes send latency; the projection-miss fold remains a separate candidate.
• Our fix design is unverified.
• We can prepare sanitized sample excerpts and the exact sampling commands on request.

[denial123789]

The handbook's Session heap guide already covers the synchronous cold-restore/event-loop risk, separates restore duration from event-loop delay, and explicitly treats #4807 measurements as incident evidence rather than a universal benchmark. Relevant guide: https://github.com/sandbaseai/deepseek-harness-handbook/blob/main/docs/en/operations/session-heap-growth.md

[denial123789]

v0.5.265 refines the handbook's Session restore guide with this discussion's intermittent live-sampling evidence: pulsing hot paths must be sampled across multiple rounds, and projection-miss latency must remain distinct from restore cost. Release: https://github.com/sandbaseai/deepseek-harness-handbook/releases/tag/v0.5.265

[yangfei222666-9]

Thanks for pointing us to the sandbaseai/deepseek-harness-handbook guide and its v0.5.265 handbook release. I verified that the tag resolves to commit 1831a6e. For authority clarity, I am treating the handbook as a community reference, not as upstream DeepSeek Harness documentation or maintainer confirmation.

Point by point:

1. For the rc.2 source boundary, the versioned guide describes the synchronous Session.fromRestore() seed-event loop and limits the conclusion to an event-loop-blocking risk proportional to the restored graph. It does not establish a particular wrapper timeout, watchdog termination, or universal event-count threshold.
2. The guide treats [Bug report] 0.1.1-rc.2 macOS: web backend crash loop & hotfix-reversion issues (repro + local fixes attached) #4807's measurements as incident evidence rather than an official or universal benchmark. Its isolation procedure also calls for measuring event-loop delay and HTTP latency separately from total restore duration.
3. The v0.5.265 #4911 passage documents evidence reported in this discussion: the suspected Array.some hot path dominated some five-second samples but was nearly absent in others, while the one-second CPU series pulsed. This documentation is not an independent reproduction. The passage also states that the samples do not identify a unique JavaScript root cause or prove that the candidate path caused send latency.
4. The guide keeps projection-miss latency distinct from restore cost. In Follow-up to #4807: live hot-path evidence correlated with our current locally patched rc.2 profile #4911, projection miss remains a separate candidate; the sampled window did not show that it occurred or caused latency. If it is measured later, it should be reported separately rather than folded into restore cost.

These statements are consistent with the explicit evidence limits in #4911.

Cannot claim from the handbook cross-reference or #4911 alone: an independent reproduction or validation; official or upstream-canonical status within the DeepSeek Harness project; a unique JavaScript function or RPC endpoint; that projection miss occurred in the sampled window; causality for send latency; a universal benchmark or current-upstream behavior; correctness of our proposed fix; or DeepSeek Harness maintainer acceptance, adoption, or a shipped upstream fix.