[rushd][WS3] Daemon lifecycle, reload & warm-set
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Quiet
- Tech stack
- nodejs, typescript
- Domain
- build-system, tooling
Research direction
Start with rush-client-core and the host readiness signaling described in the scope, then read dependencies #5895, #5896, and #5897. Trace the daemon lifecycle, reload, restart, idle-shutdown, crash-recovery, and warm-set requirements against the acceptance criteria. Done means lifecycle, concurrency, and eviction tests cover the listed invariants and CI is green.
Written by the indexing model from the issue text.
Description
Own the daemon's whole lifecycle and memory footprint: client auto-start, fingerprint-driven reload tiers, install/update self-restart with socket handoff, version-mismatch restart, idle auto-shutdown, and stale-socket/crash recovery — plus best-effort warm-set management (LRU idle eviction under a memory budget, telemetry-weighted warm selection, and its config surface) that never affects build correctness.
Depends on: #5895; #5896; #5897
Scope
- Client auto-start. In
rush-client-core, paired with host readiness signaling: a start-lock to avoid a thundering herd, a detached spawn that survives the starting client, awaiting the ready signal, and backoff on failure. - Reload tiers. After each
EXCLUSIVEcommand, compute an inputs fingerprint and pick a tier — 0 hot (no reload), 1 soft reload (re-read config/graph), or 2 hard restart (new process). - install/update self-restart. Run the mutation, send the requesting client its exit code first, then drain, kill runners, spawn a successor, and hand off the socket (clients connecting during handoff transparently retry).
- Version-mismatch restart. Trigger a Tier-2 restart on version skew (client expects Y, daemon runs X) and retry the request.
- Idle shutdown & crash recovery. Shut down after an idle timeout (active runners inhibit shutdown); detect a stale socket/PID from a crashed daemon and auto-start a replacement.
- Warm-set eviction. Auto-evict idle operations LRU under a budget (
closeRunnersAsync(cold)+ watcher teardown + record drop), never evicting active-and-subscribed operations. - Telemetry-weighted warming. Warm-select operations from the graph's per-op telemetry (
score = (timeSaved × frequency) / residentMemory), sharing one ranking with eviction so warming and eviction never disagree. - Warm-set config. Expose
warmIdleTimeoutSeconds,warmMemoryBudgetMB,warmSetMaxProjects, andautoWarmByTelemetry; all warm-set behavior is best-effort and never correctness-affecting.
Acceptance criteria
- N concurrent first-invocations start exactly one daemon (start-lock holds under a race); the daemon spawns detached and survives the starting client; start failures back off with an actionable error (falling back to in-process where applicable).
- Known input deltas map to the expected reload tier (no change → 0, config change → 1, version/engine change → 2); the fingerprint is stable for unchanged inputs and changes when relevant inputs change.
- On install/update the requesting client receives its exit code before the restart begins, the successor takes over the socket with no dropped client (in-flight connections retry and succeed), and the warm graph is rebuilt against post-install/update state.
- A forced version skew triggers a Tier-2 restart into the expected version and the client's request then succeeds, with no orphaned old-version daemon left behind.
- The daemon exits after the configured idle timeout (an in-flight runner prevents shutdown until it finishes); a stale socket/PID is detected and a replacement auto-starts on the next request.
- Eviction keeps resident memory under the configured budget by dropping LRU cold operations and never evicts active-and-subscribed operations (invariant asserted under load).
- A single deterministic ranking drives both warm selection and eviction, preferentially warming/retaining higher-value operations (high
timeSaved × frequency, low memory); warm-set behavior is best-effort and correctness is unaffected when telemetry is absent. - All four warm-set knobs are schema-validated with documented defaults, reject invalid/out-of-range values, and take effect at runtime; changing any knob only affects footprint/latency, never build correctness.
- Lifecycle, concurrency, and eviction paths are covered by tests; tests green in CI.
Part of #5894.
- Dominant language
- TypeScript
- Stars
- 6.5k
- Forks
- 708
- Avg merge
- 5d 19h
- Merged PRs (30d)
- 48
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from microsoft/rushstack
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
All issues in microsoft/rushstack
Similar issues
-
clawsweeper:linked-pr-open clawsweeper:no-new-fix-pr clawsweeper:source-repro impact:message-loss issue-rating: 🦞 diamond lobster maturity:stable P2
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Eynzof/Hermes-CN-Desktop#616 ·
-
ZCode 3.14.3 に対応する Open
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
supermomonga/zcode-acp#24 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
growthbook/growthbook#7100 ·
-
triage
Difficulty 1/5 1-3 hours Newbie friendliness 88/100