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>
20 lines
815 B
Markdown
20 lines
815 B
Markdown
# 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 start` accepts `--route-timeout <seconds>` (float, default 30.0)
|
|
- [ ] Value is passed through to `TorchNodeServer` and used in the `/v1/route` HTTP call
|
|
- [ ] `TorchNodeServer` exposes `route_timeout` as a readable property
|
|
- [ ] Test: setting `--route-timeout 45` is reflected as `45.0` on the running server object
|
|
- [ ] `python -m pytest` passes
|