Skip to content

[Feature]: keep Responses fetch helpers on a transport-only import boundary #2434

Description

@Ingwannu

Area

Proxy and routing

What are you trying to accomplish?

Keep src/server/responses/fetch-helpers.ts as a true transport leaf so ordinary Responses, compact, and native-chat imports load only the code required for request pacing, upstream HTTP-version policy, and the optional Codex WebSocket transport.

What prevents this today?

The original responses.ts split in commit e7f24b952 copied the monolith import header into fetch-helpers.ts. The file now has 39 distinct runtime import specifiers even though its exports use only the WebSocket transport, request pacing, upstream HTTP-version helper, and type-only server/config declarations.

Because ESM evaluates static imports, importing safeHostLabel, providerFetch, or fetchWithHeaderTimeout currently reaches a 326-module transitive graph including bridge, config, parser, compaction, routing, combos, OAuth, web-search, vision, Codex auth/routing, retries, sidecars, logging, and relay modules. A static walk of the imports actually used by the helper reduces that graph to six modules.

This is an ownership and startup-isolation defect, not a request-behaviour feature: src/server/chat-native.ts should not pull the full routed Responses/sidecar graph merely to call a transport helper.

What should OpenCodex do?

Preserve every public helper and wire behaviour while removing stale runtime imports from fetch-helpers.ts. Add a repository regression that locks the module to a small explicit runtime-import allowlist and ignores type-only edges. Document why the helper must remain transport-only so a future mechanical extraction or copy does not recreate the eager graph.

The change must not move request logic, change pacing, alter HTTP/WebSocket selection, or modify authentication, credentials, provider routing, retries, response parsing, or sidecar behaviour.

Example usage or interface

No CLI or config change is expected. The maintained invariant should be equivalent to:

src/server/responses/fetch-helpers.ts
  runtime imports:
    ./ws-upstream
    ../../providers/request-pacing
    ../../lib/upstream-http-version
  type-only imports:
    bun
    ../../types
    ../ws-bridge

Importing safeHostLabel from src/server/chat-native.ts must continue to behave identically without eagerly evaluating unrelated Responses, combo, OAuth, web-search, or vision modules.

Alternatives or workarounds

Leaving the stale imports in place is functionally tolerated today because most imported modules avoid harmful top-level side effects, but it makes startup/import ownership depend on that accidental property and increases the surface loaded by every consumer.

Moving the helpers again would add churn without fixing the root cause. The smallest durable change is to prune the copied imports and pin the leaf boundary with a focused source-graph test.

Additional context

Checks

  • I searched existing issues and documentation.
  • This request describes a concrete OpenCodex workflow rather than merely naming a desired technology.
  • I removed secrets and personal data.

Metadata

Metadata

Assignees

No one assigned

    Labels

    account-poolOAuth, credentials, Codex pool, quota, failover, plansenhancementNew feature or requestlanded-via-maintainerOriginal PR closed after landing via a maintainer merge trainproxyHTTP proxy, routing, reverse-proxy / management authstreamingSSE, WebSocket, terminal stream framestoolstool_calls, MCP, web-search / sidecar tools

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions