fix(provider-usage): prefer proxy-aware fetch for Codex usage loads#78753
fix(provider-usage): prefer proxy-aware fetch for Codex usage loads#78753mgustimz wants to merge 7 commits into
Conversation
When HTTP_PROXY/HTTPS_PROXY env vars are set, Codex provider usage fetches were failing with 'fetch failed' because loadProviderUsageSummary() only used resolveFetch(opts.fetch) which doesn't respect env proxy settings. Now resolves proxy-aware fetch from env first (via resolveProxyFetchFromEnv) before falling back to the explicitly-provided fetch or global fetch. Fixes openclaw#78714
|
Codex review: needs real behavior proof before merge. Reviewed June 1, 2026, 1:07 AM ET / 05:07 UTC. Summary PR surface: Source +4, Tests +19. Total +23 across 2 files. Reproducibility: unclear. The review failed before ClawSweeper could establish a reproduction path. Review metrics: none identified. Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Risk before merge
Maintainer options:
Next step before merge
Review detailsBest possible solution: Retry the Codex review after fixing the execution failure. Do we have a high-confidence way to reproduce the issue? Unclear. The review failed before ClawSweeper could establish a reproduction path. Is this the best way to solve the issue? Unclear. Retry the review first so ClawSweeper can evaluate the actual issue and fix direction. AGENTS.md: unclear because the file could not be read completely. Codex review notes: model gpt-5.5, reasoning high; reviewed against d925249ac086. Label changesLabel justifications:
Evidence reviewedPR surface: Source +4, Tests +19. Total +23 across 2 files. View PR surface stats
What 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
|
…ence
- Test that proxy-aware fetch is used when HTTP_PROXY/HTTPS_PROXY env vars are set
- Test that opts.fetch is still used as fallback when no proxy env is set
- Updated existing 'throws when fetch is unavailable' test to pass env: {} to avoid proxy interference
…nValue TypeScript expects Promise<ProviderUsageSnapshot | null | undefined> but mockReturnValue(null) gives type null directly.
6819a8b to
7c02c54
Compare
…entry - Priority: explicit fetch > env proxy > global fetch (P2 fix) - Add CHANGELOG.md entry for openclaw#78714 (P3 fix) - Update test to reflect explicit fetch takes precedence - Remove test that assumed proxy env bypasses opts.fetch
8dd498b to
8cc0a27
Compare
8cc0a27 to
a9c2a88
Compare
|
This pull request has been automatically marked as stale due to inactivity. |
Summary
When
HTTP_PROXY/HTTPS_PROXYenv vars are set, Codex provider usage fetches fail withfetch failedbecauseloadProviderUsageSummary()didn't respect env proxy settings when an explicit fetch wasn't provided.Root cause
In
src/infra/provider-usage.load.ts, the fetch function was resolved as:This bypasses env proxy settings. When direct Node fetch to chatgpt.com times out (but an HTTP proxy is available and configured in env), the usage call would consistently fail.
Fix
Changed to check env proxy when no explicit fetch is supplied:
Priority: explicit fetch override > env proxy > global fetch.
resolveProxyFetchFromEnv()already exists in./net/proxy-fetch.tsand is used in other places (e.g.,openrouter-model-capabilities.ts:188,runner.entries.ts:606). This aligns the provider-usage path with existing patterns.Changes
opts.fetchis suppliedTesting
prefers proxy-aware fetch from env when HTTP_PROXY is set and no explicit fetch is suppliedfalls back to opts.fetch when no proxy env is setFixes #78714