mirror of
https://github.com/open-jarvis/OpenJarvis.git
synced 2026-07-28 14:07:55 +00:00
690b95e050
`jarvis serve` startup was slow on two counts addressed here: 1. discover_engines() probed each registered engine's health() serially, and every probe is a blocking network check with its own ~2s timeout — so N dead/slow localhost ports cost N*2s. Run the probes concurrently in a ThreadPoolExecutor; the existing healthy.sort() normalizes order, so the result is identical to the serial version. health() impls are read-only on per-instance HTTP clients with no shared mutable state. 2. The PyPI update check ran a blocking urlopen (up to 3s on a cache miss) inline before dispatch, delaying every command. Move it to a daemon thread — it's best-effort and never raises. Together these remove ~10-30s from cold startup. Adds a regression test asserting discovery probes overlap (concurrency), not just that output is unchanged (covered by existing tests). Note: the larger ~30-40s win — the duplicate SystemBuilder.build() in serve.py — is NOT addressed here; it's not redundant (the second build wires a JarvisSystem the inline path never constructs) and needs a design pass. Deferred. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>