fix(minimax): correct API base URLs to api.minimax.io - #2924
Conversation
provider_catalog.yaml had api.minimaxi.chat and tensorzero.minimax.toml had api.minimax.chat — both stale. The international token-plan endpoint is https://api.minimax.io/v1 (verified via live /v1/models probe).
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
Important Review skippedAuto reviews are limited based on label configuration. 🏷️ Required labels (at least one) (1)
Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Team Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
…heck change-requests before approvals (Codex #2952) Five review findings on the REST transport, each fixed at the cause: - PR list: `gh api --paginate` emits one JSON document per page, so json.loads stopped at page one. New `_run_json_pages()` uses --paginate --slurp and flattens; the pulls list, issue comments and reviews all go through it. - check-runs: every page (list_key="check_runs"), not the 30-per-page default that under-counted pending/failed runs on busy PRs. - legacy commit statuses: /commits/{sha}/status statuses[] folded into the rollup as StatusContext, which is what the GraphQL rollup used to include. - reviews: paginated before deriving the decision. - reviewDecision: an outstanding CHANGES_REQUESTED blocks regardless of approvals (checked first); COMMENTED never changes an author's standing; DISMISSED clears it; PENDING ignored. Live-run over REST against #2952/#2924 after the change. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017g8jC7dupS2ubafo6zPQY6
…phQL (#2952) * fix(pr-monitor): REST transport — multi-node monitor runs exhaust GraphQL Measured live 2026-09-05: B850 + SPARK + CI bots running the learnings loop in one hour burned the 5000/h GraphQL budget and the monitor died mid-run (operator: "we may be graphql limited — we have rest api"). - _pr_numbers: `gh pr list --json` (GraphQL) -> `gh api repos/{repo}/pulls` (REST); `merged` state maps to closed+filter - _pr_summary: `gh pr view --json` (GraphQL) -> new `_pr_detail()` assembling the same shape from REST: pulls/{n}, issues/{n}/comments, pulls/{n}/reviews, commits/{sha}/check-runs - reviewDecision derived GitHub-style: latest SUBMITTED review per author (PENDING drafts skipped); APPROVED > CHANGES_REQUESTED - _review_thread_flags: review threads are GraphQL-only (no REST equivalent) — on rate-limit they degrade loudly to stderr instead of killing the run; comment bodies still flow (REST) Verified against official GitHub docs (2026-09-05): - check-run status: queued/in_progress/completed (+Actions-only waiting/requested/pending) — all non-completed count pending; conclusion null only while incomplete - conclusions: action_required/cancelled/failure/neutral/success/skipped/ stale/timed_out — SUCCESS_STATES {SUCCESS,NEUTRAL,SKIPPED} matches exactly - review states: APPROVED/CHANGES_REQUESTED/PENDING (+COMMENTED which counts as no decision) GitHub App stance: no local token hand-roll — GITHUB_APP.md's rule is mint via _app-token.yml (CI) only; the monitor stays token-agnostic over gh CLI auth, and REST quota is the separate, plentiful budget. Full-queue validation: 30+ PRs via REST under an exhausted GraphQL budget, 0 warnings, learnings + JSON artifacts written. * fix(pr-monitor): paginate every REST list, fold in legacy statuses, check change-requests before approvals (Codex #2952) Five review findings on the REST transport, each fixed at the cause: - PR list: `gh api --paginate` emits one JSON document per page, so json.loads stopped at page one. New `_run_json_pages()` uses --paginate --slurp and flattens; the pulls list, issue comments and reviews all go through it. - check-runs: every page (list_key="check_runs"), not the 30-per-page default that under-counted pending/failed runs on busy PRs. - legacy commit statuses: /commits/{sha}/status statuses[] folded into the rollup as StatusContext, which is what the GraphQL rollup used to include. - reviews: paginated before deriving the decision. - reviewDecision: an outstanding CHANGES_REQUESTED blocks regardless of approvals (checked first); COMMENTED never changes an author's standing; DISMISSED clears it; PENDING ignored. Live-run over REST against #2952/#2924 after the change. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017g8jC7dupS2ubafo6zPQY6 --------- Co-authored-by: Agent Zero <agent.zero@pmoves.ai> Co-authored-by: Mavis <Mavis@pmoves.local> Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
…er GraphQL throttle (#2995) * fix(pr-closeout): REST fallbacks for thread check + status rollup when GraphQL is throttled The merge wave stalled because the closeout's two GraphQL-only reads fail-closed under GitHub's secondary GraphQL throttle (rate_limit reports budget remaining while live GraphQL calls return RATE_LIMIT). Both now have a REST path: - Thread check: on throttle, GET /pulls/{n}/comments. Zero review comments = zero threads (a thread always has >=1 comment), so pass; >0 stays UNMEASURED and fail-closed. Never lets a PR merge over live feedback. - Status rollup: _fetch_pr's REST fallback set statusCheckRollup=None, which read as "unavailable" and blocked. Reconstruct it from REST check-runs + combined status (the same data the required-checks path already reads), in the exact shape _evaluate_rollup consumes. Verified: #2924 audits READY entirely over REST with GraphQL throttled. 38/38 existing pr_closeout tests pass. Closes #2987. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017g8jC7dupS2ubafo6zPQY6 * fix(pr-closeout): poll GitHub's lazily-computed mergeable instead of fail-closing on UNKNOWN Third transient the hot merge wave exposed: after an update-branch/base change, the first REST GET returns mergeable=null / mergeable_state=unknown while GitHub recomputes, and the closeout blocked ("mergeable state is UNKNOWN") on a PR that was actually mergeable. _pr_from_rest now re-GETs up to 5x (3s apart) until mergeable resolves, so the guarded merge waits the recompute out. 38/38 tests pass. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017g8jC7dupS2ubafo6zPQY6 --------- Co-authored-by: Mavis <Mavis@pmoves.local> Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Summary
provider_catalog.yaml:api.minimaxi.chat→api.minimax.iotensorzero.minimax.toml:api.minimax.chat→api.minimax.io(M2.7 + M2.1 provider blocks)Both prior URLs are stale; the international token-plan endpoint is
https://api.minimax.io/v1, verified via live/v1/modelsprobe.Verification
Note:
provider_catalog.yamlline 482-ishapi_baseonly; no other fields touched.