Repository navigation
[Bug]: OCX_FRESH_CONNECTION_HOSTS is bypassed by provider-scoped fetch transports #4992
Description
Summary
OCX_FRESH_CONNECTION_HOSTS was merged in #4977, but the policy is not applied to every physical HTTP send. A provider-scoped fetch installed by resolveProviderTransport can bypass the fresh-connection executor supplied by providerFetch().
Current dev: 6467235a85 (merge commit 5c992857bd).
Confirmed path
src/server/responses/fetch-helpers.tsbuildsdispatch, which addsConnection: closeandkeepalive: falsewhenwantsFreshConnection(input)matches.providerFetch()passes that function as the third argument todispatchOverride.- Production
oauthDispatch()insrc/server/responses/request-transport.tsselectsroute.provider.fetch ?? execute. resolveProviderTransport()installs a provider-scopedfetchfor providers such as xAI.- That provider fetch is selected instead of
execute, so the new connection policy never reaches the final send.
Impact
The operator can configure the exact affected upstream hostname and still reuse Bun's pooled connection on the provider-scoped path. The mitigation therefore does not fix the dead pooled-connection failure for the providers that need a custom transport most.
Required behavior
Apply the policy around the actual selected physical fetch, while preserving provider transport behavior, pacing, redirect ownership, auth snapshot checks, and the existing OAuth dispatch boundary.
Add an end-to-end focused regression with a provider-scoped fetch proving that the final send receives:
Connection: closekeepalive: false- the original provider-specific fetch implementation
Also add public operator documentation for the environment variable's comma-separated syntax and exact/subdomain matching; the merged change currently documents it only in an internal structure note.
Regression origin
Introduced by #4977. The general dispatch wrapper is correct, but the provider-specific override selection is outside that wrapper.
Activity
lidge-jun commentedon Sep 18, 2026
리뷰 · 우선순위 77 / 80
이 이슈는 #4977로 들어간
OCX_FRESH_CONNECTION_HOSTS가 provider-scopedfetch경로에서는 최종 send에 안 닿는다는 주장입니다. tip(e80e571f63, package 2.59.0) 체크아웃에서 경로를 따라가 보면 주장이 그대로 성립합니다. 아직 tip에 수정 커밋은 없습니다.src/server/responses/fetch-helpers.ts의providerFetch는dispatch안에서wantsFreshConnection(input)이 참이면Connection: close와keepalive: false를 넣고, 그dispatch를dispatchOverride의 세 번째 인자execute로 넘깁니다. override가 없으면dispatch가base(=provider.fetch ?? globalThis.fetch)를 감싸므로 정책이 적용됩니다. 문제는 productionoauthDispatch입니다.src/server/responses/request-transport.ts는const fetchImpl = route.provider.fetch ?? execute로 고른 뒤fetchImpl(destination, …)만 호출합니다.resolveProviderTransport()(예:src/providers/xai-transport.ts)가 설치한 providerfetch가 있으면execute(fresh-connection 래퍼)를 건너뛰고 raw provider fetch로 나갑니다.한 가지 더:
providerFetch가 override 없이 쓰이면dispatch가 provider.fetch를 감싸므로 fresh 정책이 살아 있습니다. 구멍이 “provider.fetch가 존재한다”가 아니라 “oauthDispatch가 execute 대신 provider.fetch를 고른다”는 점입니다. 그래서 회귀는 반드시 oauthDispatch(또는 동등한 dispatchOverride가 provider.fetch를 직접 호출하는) 경로를 밟아야 하고, 지금 fresh-connection-optout 스위트만으로는 부족합니다.영향은 본문과 같습니다. 운영자가 문제 host를 env에 넣어도, custom transport가 필요한 제공자(xAI Grok CLI 등)에서는 Bun keep-alive 재사용이 그대로일 수 있습니다.
tests/responses/fresh-connection-optout.test.ts는providerFetch+override가execute를 호출하는 경우와 beforeDispatch 패배를 커버하지만, oauthDispatch처럼 override가provider.fetch를execute보다 우선하는 경로의 e2e는 없습니다.structure/transports/responses.md는 “final executor boundary에서 override 이후 URL에 적용”이라고 적혀 있으나, tip 코드의 oauthDispatch 선택은 그 문장과 어긋납니다. 공개 운영자 문서(docs-site)에도 이 env 문법은 거의 없고 structure 노트 수준입니다.점수를 높게 잡습니다. tip에서 코드로 재확인된 정책 우회이고, #4977 완화의 실효 범위를 깎습니다. types/config 스플릿과 무관합니다. Preview deploy는 계획에 없습니다.
src/server/responses/fetch-helpers.ts (providerFetch/dispatch/wantsFreshConnection) - tip에서 정책 본체는 여기. override 없는 경로에서는 provider.fetch를 감쌉니다.
src/server/responses/request-transport.ts (oauthDispatch, fetchImpl) - tip 약 L398: provider.fetch가 있으면 execute 무시. 이슈의 핵심 구멍.
src/providers/xai-transport.ts (resolveProviderTransport) - attemptFetch를 provider.fetch로 설치. oauthDispatch 우선순위의 실제 소비자.
tests/responses/fresh-connection-optout.test.ts - provider-scoped fetch가 execute를 건너뛰는 oauthDispatch 회귀 없음.
structure/transports/responses.md - final executor 적용이라고 적었으나 tip oauthDispatch와 불일치.
메인테이너의 판단이 필요한 지점
너의 추천
열고 고치세요. tip 기준 버그 맞습니다. 수정 PR은 (1) 실제 선택된 physical fetch 둘레에 fresh 정책 (2) provider fetch 구현 보존 (3) oauthDispatch+provider.fetch e2e에서 Connection/keepalive 단언 (4) structure/docs 정합을 한 묶음으로. 라벨은 바꾸지 마세요.
이 댓글은 grok-bot이 작성했습니다
fix(transport): apply the fresh-connection policy to a selected provi…
lidge-jun commentedon Sep 18, 2026
Fixed on
devby #5022, squashed as56a99d3848988e8c29c9ee02fb6e8ac44aefa102.A provider-scoped transport selected at dispatch now receives the fresh-connection policy, so
OCX_FRESH_CONNECTION_HOSTSis honoured on that path rather than bypassed.Worth recording how this interacts with #4977, which landed earlier in the same round and moved the fresh-connection opt-out decision to the dispatch boundary: that change made the decision happen in the right place, and this one makes the selected transport actually carry it. Neither is redundant with the other, and the regression added here asserts the transport receives the policy rather than asserting only that the decision was made.
Shipping in the next release off
dev.fix(proxy): resolve the provider route at the physical send
fix(proxy): resolve the provider route at the physical send
Per-provider outbound egress: direct, inherit, HTTP(S) and SOCKS5 per…