Repository navigation
collect-fleet-feed poolFor still maps openai providers to retired pool id 'openai', losing burn attribution on the openai.main card (PR #5089 Codex finding) #5252
Description
Finding (from PR review)
Codex (chatgpt-codex-connector[bot]) raised this P2 finding on merged PR #5089 and it was never fixed or replied to:
- PR: feat(aggregator): rename the main ChatGPT pool openai -> openai.main #5089 — "feat(aggregator): rename the main ChatGPT pool openai -> openai.main"
- Comment: feat(aggregator): rename the main ChatGPT pool openai -> openai.main #5089 (comment) (2026-11-03T19:28:30Z, on
pm-stack/aggregator/src/quota-extract.ts:505) - Essence: "When the scraped OpenCode server has active sessions using
openai,openai-codex, orchatgpt, this rename silently removes them from the main ChatGPT quota card. Inpm-stack/aggregator/scripts/collect-fleet-feed.ts,poolForstill returns\"openai\"for these providers (lines 189-192), while the collector attachesactiveSessionsonly when that result exactly matchespool.id(line 639). Update the burn mapper alongside this rename so previously attributed sessions continue to appear underopenai.main."
No-response evidence
- The inline thread contains only the Codex comment; no reply followed it before the PR merged.
- No follow-up commit on main changes
poolFor.
Still live on current main (verified 2026-11-04 by gh api raw read)
pm-stack/aggregator/scripts/collect-fleet-feed.ts:
- Lines 191-194:
case "openai": case "openai-codex": case "chatgpt": return "openai"; - Line 641:
if (poolFor(provider, s.model) === pool.id) sessions.push(s);
pm-stack/aggregator/src/quota-extract.ts:505defines the pool asid: "openai.main"— there is no pool with idopenai, so sessions on those providers never match and never appear inactiveSessions(burn attribution) on the main ChatGPT card.
Acceptance criteria
poolFormaps the main-account providers (openai,openai-codex,chatgpt, andopenai.mainitself if it appears as a provider id) toopenai.main, so active sessions are again attached to the main ChatGPT pool card.- A test or documented check covers the provider -> pool mapping for the renamed pool.
- Or: the finding is resolved on this issue by a documented decision with reasoning recorded.
Activity
dezren39 commentedon Nov 4, 2026
🤖 Agent note · filed
dezren39 commentedon Nov 4, 2026
agent-note:v1
task: 9085
lane: code-l
stage: picked_up
next: re-verify the poolFor/openai.main finding against current main with fresh reads, record the verdict here, and route the fix packet if confirmed.
dezren39 commentedon Nov 4, 2026
agent-note:v1
task: 9085
lane: code-l
stage: done
outcome: triaged — finding CONFIRMED live on current main; fix routed as task 9091
Re-verification 2026-11-04T02:52Z (fresh gh api raw reads at ref=main):
pm-stack/aggregator/scripts/collect-fleet-feed.ts:191-194—case "openai": case "openai-codex": case "chatgpt": return "openai";pm-stack/aggregator/scripts/collect-fleet-feed.ts:641—if (poolFor(provider, s.model) === pool.id) sessions.push(s);(exact match only)pm-stack/aggregator/src/quota-extract.ts:505— pool defined asid: "openai.main"; a grep confirms NO pool with id exactly"openai"exists in quota-extract.ts.Verdict: the Codex P2 from PR #5089 is real and still live — sessions on the main ChatGPT account (providers openai/openai-codex/chatgpt) never match the openai.main pool, so their burn attribution silently vanished from the openai.main card at the rename.
Routing: fix enqueued as task 9091 (small_fix, dedupe key
repo-health:v1:fix:developing-today/code:issue:5252): poolFor returns "openai.main" for the three providers, plus a guard so a future rename cannot silently orphan a mapping. Per pr-comment-review rules, the PR #5089 thread was NOT replied to; all discussion stays here.