Scale gateway configuration timeout with config command count#707
Conversation
openclaw#652 raised the WSL configure-gateway timeout 30s->120s, but the cap was fixed while BuildConfigCommands grows with the device-pair keys and every Gateway.ExtraConfig entry. Each `openclaw config set` pays a ~4-5s cold Node start on a freshly created distro, so a config-heavy setup can creep back into the same timeout the fixed cap was meant to prevent. Budget the step by the number of config commands actually emitted (45s base + 15s/command, 180s floor) so it cannot silently regress as the command list grows, and report the computed value in the timeout message. Tests assert the scaling/floor relationship rather than a fixed constant. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
Codex review: needs real behavior proof before merge. Reviewed June 6, 2026, 9:19 PM ET / 01:19 UTC. Summary Reproducibility: no. there is no live high-confidence reproduction from this review. Source inspection does show the current 120s fixed timeout and a config command builder that grows with device-pair and Review metrics: 2 noteworthy metrics.
Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Proof guidance:
Risk before merge
Maintainer options:
Next step before merge
Security Review detailsBest possible solution: Land the scoped dynamic timeout after maintainers accept the longer setup wait tradeoff and the contributor adds redacted real WSL proof for a config-heavy configure-gateway run. Do we have a high-confidence way to reproduce the issue? No, there is no live high-confidence reproduction from this review. Source inspection does show the current 120s fixed timeout and a config command builder that grows with device-pair and Is this the best way to solve the issue? Yes, the proposed direction is narrow and maintainable: compute the WSL timeout from the generated config command list and cover the scaling/floor behavior in setup-engine tests. The remaining gap is real WSL behavior proof, not a different code shape. AGENTS.md: found and applied where relevant. Codex review notes: model gpt-5.5, reasoning high; reviewed against 4be005707f44. Label changesLabel changes:
Label justifications:
Evidence reviewedWhat I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
|
Problem
#652 raised the WSL
configure-gatewaytimeout 30s→120s, but the cap is fixed whileBuildConfigCommandskeeps growing — it appendsopenclaw config setcalls for the device-pair public URL,device-pair.enabled, and everyGateway.ExtraConfigkey. Eachconfig setspawns the Node CLI fresh inside WSL (~4–5s apiece on a newly created distro with a cold cache), so a config-heavy setup can creep right back into the same timeout the fixed cap was meant to prevent.Change
Budget the step by the number of
config setcommands actually emitted, instead of a fixed value:ConfigBaseBudget = 45s+PerConfigCommandBudget = 15s/command, floored atMinConfigurationTimeout = 180s.ComputeConfigurationTimeout(configCommands)counts the emitted commands;ExecuteAsyncuses it and reports the computed value in the timeout message (no hardcoded seconds).45 + 15×8 = 165s, floored to 180s (~3–4× the observed per-command cost); extra config keys scale the budget up automatically.Tests
ComputeConfigurationTimeout_ScalesWithConfigCommandCountandComputeConfigurationTimeout_NeverBelowFloor.ConfigureGateway_UsesExtendedTimeoutForWslConfigto assert the computed value + floor (the old test pinned the now-removed constant) andConfigureGateway_ReturnsTimeoutSpecificFailureto not hardcode the seconds. Tests assert the scaling/floor relationship rather than a magic number.Validation
Per
AGENTS.md:./build.ps1✅ (all 5 projects), SetupEngine tests ✅ 239, Shared ✅ 2049, Tray ✅ 958.🤖 Generated with Claude Code