Issue files (.scratch/issues/20-29): retrospective specs for all work done in the current sprint — hardening, route-timeout, start-layer protocol, heartbeat stats, availability map, rolling RPM, smart assignment, throughput routing, routing tests, relay outbound client. ADRs (docs/adr/0011-0014): 0011 — Auto-shard from memory budget and tracker network assignment 0012 — X-Meshnet-Start-Layer overlapping shard execution protocol 0013 — Rolling RPM statistics, smart assignment scoring, throughput routing 0014 — Relay outbound client for NAT/internet pipeline hops prd.json: US-020 through US-029 added, all marked done. ralph_progress.py now shows 29/29 complete (100%). Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
815 B
815 B
US-021 — --route-timeout CLI flag for node tracker route lookup
Status: done Priority: Medium Stage: Implemented
Context
The node's slow-path tracker route lookup (/v1/route) used a hard-coded 30-second HTTP timeout.
On high-latency links (relay, satellite, 5G) or when the tracker is under load, legitimate route
lookups were failing prematurely. The timeout is deployment-specific and should be tunable.
Acceptance criteria
meshnet-node startaccepts--route-timeout <seconds>(float, default 30.0)- Value is passed through to
TorchNodeServerand used in the/v1/routeHTTP call TorchNodeServerexposesroute_timeoutas a readable property- Test: setting
--route-timeout 45is reflected as45.0on the running server object python -m pytestpasses