Audio transcription/live-call outcome accounting pre-sets 502 before body validation

[lidge-jun]

Client or integration

Direct HTTP/API client

Area

Proxy and routing

Summary

In src/server/audio-transcriptions.ts:120 and src/server/audio-live.ts:103 (commit 81f58a4 / 4a49d7f), outcome is pre-set to 502 after a successful upstream HTTP response and only replaced after JSON/text validation. A 200 whose body is oversized, malformed, missing a call id, or fails alias registration is recorded as 502, which can feed cooldown of a healthy ChatGPT account. Native handleLive records the real upstream status before body handling, so the owned paths disagree with the native ones.

Reproduction

1. Create a live call / transcription whose upstream returns 200 with a malformed or oversized body.
2. Observe recordOutcome(502) instead of the real upstream 200 (or a body-handling-specific outcome).

Found by the 2.53.0 release regression audit (lane09). Synthesis disposition: follow-up issue — narrow accounting defect with account-cooldown blast radius; not promotion blocking.

Version

dev @ eb81eaa (post-2.52.0, pre-2.53.0)

Operating system

macOS (any; codepath is platform-independent)

Provider and model

openai (ChatGPT account pool) live/audio routes

Logs or error output

N/A

Screenshots and supporting files

N/A — evidence is source-level, cited inline.

Redacted configuration

N/A

Checks

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.

[lidge-jun]

리뷰 · 우선순위 56 / 80

설명
이 이슈는 ChatGPT 계정 풀이 쓰는 소유(owned) 오디오 경로의 결과 기록이, 업스트림 HTTP 200 뒤에 본문 검증 실패를 502로 남겨 건강한 계정을 쿨다운에 넣을 수 있다는 회계 버그다. src/server/audio-transcriptions.ts와 src/server/audio-live.ts는 업스트림 응답을 받은 뒤 outcome = upstream.ok ? 502 : upstream.status로 미리 찍고, JSON/용량/call id/alias 등록이 끝난 뒤에야 outcome = upstream.status로 고친다. 그 사이(또는 본문 처리에서 return하는 경로)에 기록되면 200이 502로 남는다. 네이티브 handleLive는 업스트림 status를 본문 처리 전에 진짜 값으로 남기는 쪽이라, 소유 경로와 네이티브 경로가 어긋난다.

지금 HEAD(8e6c99608)에도 해당 패턴이 그대로 있다. transcription은 ok면 502로 시작했다가 text 필드 확인 후 status로 바꾸고, live도 call id·alias 성공 후에야 status로 되돌린다. 본문이 너무 크거나 JSON이 깨지거나 call id가 없으면 클라이언트에 502를 주는 것 자체는 타당할 수 있다. 문제는 그 502가 “업스트림이 죽었다”는 신호로 계정 풀에 들어가면, 실제로는 200을 준 건강한 ChatGPT 계정이 쿨다운·회피 창에 들어간다는 점이다. 오디오 스택(#4391/#4392/#4395) 위에 쌓인 회계 구멍이고, 2.53.0 회귀 감사 lane09 follow-up이며 프로모션 블로커는 아니라고 본문에 적혀 있다.

우선순위 56은 쿨다운 오탐 반경이 있지만 재현이 “200 + 불량 본문”으로 좁고, 수정이 outcome 초기값·early-return 기록 정리로 국소적이기 때문이다. package 2.54.0 tip에서도 그대로라 작은 회계 패치로 넣기 좋다. types/config 분할과 무관하다.

라인 문제
src/server/audio-transcriptions.ts outcome = upstream.ok ? 502 : upstream.status - 성공 HTTP를 본문 검증 전 502로 가정. 검증 실패 early-return 시 502 회계가 남을 수 있다.
src/server/audio-live.ts 동일 패턴 - call id 없음/빈 본문/alias 실패 경로와 outcome 갱신 순서가 어긋나면 풀 쿨다운 오탐.
심볼 네이티브 handleLive - 업스트림 status를 먼저 기록. owned 경로와 불일치.
심볼 recordOutcome / account-pool cooldown - 502가 “업스트림 장애”로 해석되면 건강한 ChatGPT 계정이 빠질 수 있다.

메인테이너의 판단이 필요한 지점

• 본문 검증 실패를 502(프록시/업스트림 불량)로 둘지, 4xx/별도 outcome 코드로 풀 쿨다운에서 제외할지.
• transcription과 live를 한 PR로 맞출지, live(alias 등록)만 먼저 할지.

너의 추천
두 파일 모두 outcome 초기값을 upstream.status로 두고, 본문/alias 실패는 풀 쿨다운에 안 넣는 분류(또는 기록 생략)로 맞추는 작은 PR을 열자. 네이티브 handleLive와 주석으로 계약을 같게 적어 회귀를 막자.

이 댓글은 grok-bot이 작성했습니다

[lidge-jun]

Landed via #4512 at 9b2fc10 — audio transcription/live routes now record the real upstream status before body handling.

이 댓글은 grok-bot이 작성했습니다