Request logs can miss successful ChatGPT native passthrough turns #44

Summary

I am seeing a request-log gap for successful ChatGPT/native passthrough turns. Routed providers such as umans and opencode-go appear in /api/logs, but successful gpt-5.5 / chatgpt turns do not show up. A non-stream chatgpt 503 does show up, so the issue seems specific to successful native passthrough SSE finalization rather than all ChatGPT requests.

This looks like a follow-up edge case around the native passthrough SSE workaround from #31.

Observed evidence

Current runtime:

• ocx status --json reports proxy v2.6.0, PID 32544, health OK, default provider chatgpt.
• Codex is configured to route through opencodex at http://localhost:10100/v1.
• /api/logs currently groups as:
  • umans: 104 entries, all 200
  • opencode-go: 18 entries, all 200
  • chatgpt: 1 entry, 503
• The only chatgpt entry is:
  • local time 2026-06-28 16:44:07 +09:00
  • model gpt-5.5
  • status 503
  • errorCode server_is_overloaded
  • closeReason non_stream
  • usageStatus unreported
• During the same session, Codex session JSONL showed completed gpt-5.5 turns with model_provider: "opencodex" / comp_hash: "opencodex", but those successful turns were not visible in /api/logs.
• The proxy stdout log repeatedly contains:

1 | (function (controller, error) {"use strict";
              ^
TypeError: null is not an object

Code path that looks suspicious

In src/server.ts, native passthrough SSE uses upstreamResponse.body.tee():

• branch 0: returned directly as the client-facing Response body via markNativePassthroughSseResponse(...)
• branch 1: consumed in the background by consumeForInspection(...)

Then responseWithDeferredRequestLog(...) skips normal request-log wrapping for native passthrough SSE responses:

if (isNativePassthroughSseResponse(response)) {
  return response;
}

So successful native passthrough logs depend on the background inspection path calling onNativePassthroughTerminal.

The cancel path looks like it can suppress finalization:

• consumeForInspection(...) sets cancelled = true and calls reader.cancel(...) when the signal aborts.
• The fallback terminal reporting uses if (!reported && !cancelled) onTerminal("incomplete").
• /v1/responses passes onNativePassthroughCancel, but if the inspection pump exits through the early aborted/cancelled path, it looks possible for neither onNativePassthroughTerminal nor onNativePassthroughCancel to finalize the request log.

That would match the observed pattern:

• routed providers use the normal logging path and appear in /api/logs
• non-stream ChatGPT failures appear
• successful ChatGPT passthrough SSE responses can reach Codex but not finalize a request-log entry

Possible related factor

/api/logs is also memory-only (requestLog: RequestLogEntry[] = [], max 200). If the proxy crashes/restarts during the same window, successful entries from the previous process are lost. That may be a separate limitation, but the native passthrough finalization path still looks worth hardening so a successful/cancelled passthrough request always records exactly one terminal log entry when possible.

Questions

1. Should native passthrough SSE finalize /api/logs on client cancel / inspection pump abort, probably as 499 with closeReason: "client_cancel"?
2. Should consumeForInspection(...) call a terminal/cancel callback even when the abort signal sets cancelled = true?
3. Would you prefer a focused PR with a regression test for native passthrough SSE cancel/finalization, or is this better handled as part of a broader request-log persistence/logging change?