You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
atlas-search: via-service client should honor proxy env (ureq Proxy::try_from_env) #5597
Found during the step-6 cutover (#5356): the via-service client in crates/atlas-search/src/service.rs builds its ureq agent with timeouts only — no proxy support. On hosts that reach the tailnet only through an HTTP CONNECT proxy (the sandbox: its tailnet tunnel proxy is the same egress host on port 3130), ATLAS_SEARCH_URL=http://amd-6.raptor-pumpkinseed.ts.net:18760 is therefore unreachable directly: the connect times out and the CLI falls back to standalone. The fallback is loud and correct (verified live — warning on stderr, standalone results identical), so this is a capability gap, not a correctness bug.
Interim state (working, shipped in the cutover): the sandbox's atlas-search wrapper asks the shared laptop-ssh control connection to forward loopback:18760 to the laptop and points ATLAS_SEARCH_URL at http://127.0.0.1:18760. That works (1.7s dedupe-class responses vs ~9.5 min for a standalone hybrid search over the proxy path), but it couples the CLI to the SSH tunnel.
Ask: build the client agent with proxy-from-environment support (ureq 3: Proxy::try_from_env or equivalent, honoring HTTPS_PROXY/http_proxy + NO_PROXY), with a test that runs the client against a stub CONNECT proxy. Then the sandbox wrapper reduces to setting ATLAS_SEARCH_VIA=service + ATLAS_SEARCH_URL, and any other proxied host (codespaces, CI) gets the same path for free.
Note the related asymmetry: the sandbox's egress proxy (port 3128) cannot complete TLS to tailscale serve --https endpoints, while the tailnet tunnel proxy (3130) reaches the fleet-standard tailscale serve --tcp forwards — the atlas serve mapping is therefore the tcp form. Proxy support in the client makes both forms usable from the sandbox.
Task: Claim evaporated — the previous holder's claim on task 10083 ended without a terminal verb and the task is queued unclaimed (attempts 6/6, last checkpoint stage: handed_off). Labels reset to the truth: queue/queued + status/needs-triage. The fleet monitor's dead-in-queue pass this run also doubled the attempt cap (6 -> 12) where it had been reached.
Expectation: the next queue claimant picks up task 10083 from the handed_off checkpoint; no work was lost.
Activity
developing-today commentedon Nov 4, 2026
CODE-1384
dezren39 commentedon Nov 5, 2026
🤖 Agent note · handed off
dezren39 commentedon Nov 5, 2026
🤖 Agent note · handed off
developing-today commentedon Nov 5, 2026
🤖 Agent note · state: handed off
dezren39 commentedon Nov 5, 2026
🤖 Agent note · handed off
opencode, so this task is handed off; the laptop claimant launches the bound opencode session which drives it to its terminal state.dezren39 commentedon Nov 5, 2026
🤖 Agent note · handed off
opencode(repeat handoff, attempt 3/6)65 remaining items
dezren39 commentedon Nov 6, 2026
🤖 Agent note · handed off
dezren39 commentedon Nov 6, 2026
🤖 Agent note · handed off
dezren39 commentedon Nov 6, 2026
🤖 Agent note · handed off
dezren39 commentedon Nov 6, 2026
agent-note:v1
task: 10083
lane: code-q
state: parked (handed off)
execution_lane: opencode
next: opencode claimant launches the bound session for task 10083
verified: issue #5597 OPEN, no hard-stop labels (held/user/owned/do-not-merge/do-not-auto-edit absent), fresh gh check 2026-11-06
dezren39 commentedon Nov 6, 2026
agent-note:v1
task: 10083
lane: code-v
state: parked (handed off)
execution_lane: opencode
next: opencode claimant launches the bound session for task 10083
verified: issue #5597 OPEN, no hard-stop labels (held/user/owned/do-not-merge/do-not-auto-edit absent), fresh gh check 2026-11-06