[Bug report] 0.1.1-rc.2 macOS: web backend crash loop & hotfix-reversion issues (repro + local fixes attached)

[yangfei222666-9]

Environment: DeepSeek Harness 0.1.1-rc.2 (local official clone HEAD b150a551b8d465e31e418e1b2eaf5e79bbb7d28e), macOS desktop app; desktop-managed dsh web logged at 127.0.0.1:3080.

We observed repeated local restart/termination incidents and investigated them with local logs, synthetic repros, and the official HEAD source. The claims below are scoped to those artifacts; our local fixes remain candidate-only. The repository README directs feedback and bug reports to Discussions.

---

1. Local module-resolution drift: in one observed boot, resolver evidence pointed to the profile copy

In our local setup, changing the global runtime copy under ~/.local/share/node/.../node_modules did not change the resolver target for the boot under diagnosis. That resolver targeted the profile copy under ~/Library/Application Support/DeepSeek Harness/home/profiles/web/node_modules/, so the global-only change appeared ineffective until the profile copy was aligned.

• Evidence: while the global file was 9ac432ba…, two native samples showed an ArraySome-dominated HTTP-active path, and the boot resolver targeted profile bytes 7f9b8562…, whose source still used sessionBlank(session.events.some(...)). The native samples did not directly name the JavaScript function or endpoint; sessionBlank is a source/load-path correlation.
• After profile alignment and a restart, the pre-open idle CPU pulse was no longer observed. This was not a single-variable experiment and does not prove sole causation or a universal package-resolution rule.
• Suggestion: make the real runtime load path a single source of truth, or validate/alert on copy divergence and document the override rule.

2. Synchronous giant-session restore can stall the event loop; historical crash-loop attribution remains PARTIAL

Official HEAD PersistenceCoordinator.prepareCore() loads and adopts stored events, then enters session preparation with seedSource: 'persistence'. Session.fromRestore() synchronously iterates the restored seed, validates each event, and freezes restored objects. Isolated synthetic tests on this machine reproduced event-loop blocking in that synchronous section.

A controlled local trial on the approximately 2.03M-event target coincided with CPU saturation and a backend death. Separately, app-launch.log contains 48 "sustained health-probe failure confirmed; terminating owned child" messages across three UTC dates. Those 48 log messages are not attributed en masse to the restore mechanism.

• Synthetic measurements: a 2M-event restore had a 403.033 ms maximum heartbeat gap with 0 pending ticks. A 1M-event full prepareCore() had a 252.501 ms maximum gap. A single 1M-wide message had a 266.967 ms maximum gap. The exact 2,033,163-event full-pipeline case is also synthetic, not a claim about the exact live-session count.
• After our local chunked-async candidate (8 ms yield budget), the 2M synthetic restore had an 18.680 ms maximum gap with 48 pending ticks. A later bounded Gate G v3 receipt for the approximately 2.03M-event target recorded CPU 99%→9.4% within 12s, HTTP 200 with 1.4 ms reported latency, and no process death. That validates only the recorded local trial.
• Attribution boundary: historical crash-loop attribution remains PARTIAL. Earlier failures may also have involved the profile/global resolution drift above. We do not claim the synchronous restore path was the sole or complete cause of past terminations.
• Suggestion: chunk the validation/deep-freeze preparation and yield to the event loop while preserving the immutable contract; alternatively, lazy-load or warn before restoring oversized sessions.

3. Four linear-scan sites can traverse the full log in worst cases; only sessionBlank has a local hot-sample correlation

• sessionBlank: session.events.some(...); it can stop early, but scans the full log when no turn/start exists.
• resolveSessionPreset: reverse loop; it scans the full log when no later selection exists.
• backscanArgs: history scans only its page, while a live table miss may read the session snapshot and reverse-scan it; after append, that snapshot may need rematerialization.
• session.attachment: the attached-session path copies the event snapshot, then scans events and nested content until a reference matches; a late match or miss can traverse the full log.

Only sessionBlank is correlated with our local ArraySome sample through the resolver/source evidence above. The other sites are official-HEAD static scalability candidates. We have a local candidate patch for the four sites, but local static checks and patch artifacts do not establish upstream correctness or measured user impact.

4. Interactive approval/request snapshot reads and backward scans

On official HEAD, the interactive approval path reads session events to check open-turn and policy state. After appending approval/asked, the host handler reads the post-append snapshot and scans backward to pair the pending request. These scans can stop early, but a no-match or no-near-match path can traverse to the beginning, and the post-append getter can rebuild the snapshot. Already-aborted and never policy paths do not enter the host pending-ask backscan.

Our local candidate uses eventAt() with a current-turn boundary and a 10,000-event cap; its extracted-handler tests passed 14/14. This remains a local candidate, and we have not attributed observed crashes or latency to this path.

Local patch-management note — not an upstream bug

In our local profile, stale patch/workspace/lock metadata caused an ordinary pnpm install in isolated copies to reconstruct older locally configured host and persistence bytes. After correcting our local registrations and lockfile, isolated replays preserved the candidate patch set. This was a local hot-patch management/configuration breakpoint, not evidence of an official DSH or pnpm packaging defect. We did not run that install on the live profile.

---

Scope of local validation: the restore candidate has synthetic measurements plus one bounded live receipt; the scan candidates have source/static or extracted-handler checks; the pnpm note has isolated replay; and global/profile byte alignment was checked by hash and cmp at the recorded audit points. These scopes do not establish upstream or current runtime readiness.

Cannot claim: the synchronous restore path was the sole cause of every historical restart; the native CPU sample directly named sessionBlank; the pnpm profile incident is an upstream packaging defect; the local scan patches are upstream-correct; official HEAD has passed a clean live end-to-end reproduction; or any repo-wide, current-runtime, or production PASS beyond the scoped receipts above.

Timezone correction: app-launch.log uses UTC Z timestamps; the earlier no-new-writes interpretation was incorrect and has been removed.

Re-published after independent review; withdrawn draft replaced

[liyangbing]

The rc.2 source supports one important boundary in this report, while leaving the desktop attribution open. PersistenceCoordinator.prepareCore() awaits the backend read, adopts/checks the stored events, adds interrupted-turn closers, and calls ctx.sessions.prepare(..., { seedSource: "persistence" }). Session.fromRestore() then synchronously walks the complete seed: envelope/header/message checks, surface transition validation, object-graph freezing, and log.push() all happen in that loop. That makes event-loop starvation during a very large cold reconstruction technically plausible. It does not establish a universal event-count threshold or prove which process initiated a historical termination.

For future receipts, I would bind four clocks before changing either package copy:

1. desktop/main PID and start time;
2. Web Host PID/PPID, exact command, listener, and resolved package realpaths;
3. Session-open time, last successful probe, first failed/slow probe, and any deliberate supervisor decision;
4. Host exit/signal and replacement PID.

A useful isolation ladder is: fresh Session in the same process → copied stopped-writer artifact → fixed-shape small/large fixtures → direct Host versus desktop-managed Host with identical bytes → one proven package closure. If the Host remains alive and eventually responds while only the wrapper-owned child is terminated, that isolates supervision policy from Host failure. If both paths load different realpaths, restore one supported installation owner before measuring again. Do not patch both the global and profile copies: that removes the discriminator and creates a hybrid build.

Also preserve the original home and Session artifact. A blank home can restore service but cannot prove recovery; use a separate diagnostic home and reintroduce only copied evidence.

I turned this into a source-pinned operator section with a process-timeline template, isolation ladder, and result matrix: https://github.com/sandbaseai/deepseek-harness-handbook/blob/main/docs/en/operations/session-heap-growth.md#route-a-cold-restore-restart-loop

[yangfei222666-9]

Adding a consolidated, evidence-backed version of my earlier reply so the measurements, operational sequence, and limitations are in one place.

Thanks for the source-pinned review and the operator templates.

On attribution, agreed: our revised report keeps historical crash-loop attribution PARTIAL. In local app-launch.log, the first matching record was 2026-08-25T15:05:14.089Z and the last was 2026-08-27T21:23:56.609Z; across that interval the log contained 48 exact sustained health-probe failure confirmed; terminating owned child messages. Those are 48 supervisor log messages, not proof of 48 same-cause process deaths. Separately, one controlled opening of the approximately 2.03M-event target coincided with CPU saturation and a backend death. The prepareCore → fromRestore source walk and our isolated measurements make event-loop starvation technically plausible, but they do not close desktop-side or historical per-termination attribution.

The detailed synthetic measurements were about the longest uninterrupted event-loop gap, not faster total restoration:

• In the isolated 2M direct-restore case, maximum heartbeat gap changed from 403.033 ms with 0 pending ticks to 18.680 ms with 48 pending ticks for the global local candidate. Total fromRestore wall time increased from 400.666 ms to 801.425 ms; the intended improvement was cooperative fairness.
• In the 1M full-prepareCore case, maximum gap changed from 252.501 ms to 21.386 ms for the global candidate.
• For a single 1M-wide message, maximum gap changed from 266.967 ms to 28.128 ms in both global and profile candidates.

Separately, one bounded local observation recorded under the Gate G v3 label for the approximately 2.03M-event target showed CPU falling from 99% to 9.4% within 12 seconds, HTTP 200 with a reported 1.4 ms latency, and no process death during that observation. I am not calling that a formal Gate G v3 PASS: the prewritten gate required a CPU peak below 80% plus additional HTTP, PID/reconnect, first-byte, and UI fields that this receipt did not fully capture. It is one bounded live observation, not long-term or repo-wide runtime readiness.

On the load-path issue, the criticism about patching both copies is fair. During one recorded boot, resolver evidence pointed to profile host-apiproxy bytes 7f9b8562… while the global reference was already 9ac432ba…; that is a boot-specific resolver/source correlation, not direct proof of the process's ESM cache or a universal resolution rule. We aligned the profile copy to the modified global copy. After that alignment and a restart, the pre-open idle CPU pulse was no longer observed, but this was not a single-variable experiment and does not prove sole causation. The alignment also removed load-path divergence as a diagnostic discriminator and left room for a hybrid installation state.

The pnpm sequence has two distinct phases. Before FIX-8 corrected the active patch registrations and lockfile, an ordinary install in an isolated copy reconstructed the older configured host and persistence bytes. After that correction, isolated empty-tree ordinary install, existing-tree-clone ordinary install, and frozen/offline replay all reproduced the seven recorded patch outputs byte-for-byte. We did not run that install on the live profile. A fresh read-only check immediately before this consolidated reply found the selected global/profile main files pairwise byte-identical for host, session, and persistence; however, a later local send-repair changed the host bytes after the FIX-8 replay baseline, so reinstall persistence for the current host bytes has not been revalidated.

For any future recurrence, we'll capture the four clocks before changing either package copy: desktop main PID/start; Host PID/PPID/command/listener/realpaths; session-open/probe timeline; and exit/signal/replacement PID. We'll also keep one supported installation owner and use the isolation ladder you proposed: fresh session → copied stopped-writer artifact → fixed-shape fixtures → identical-bytes Host comparison → one package closure.

If useful, we can prepare a sanitized four-clock template and a separately reviewed export of the existing RED/GREEN restore harness and results.