Skip to content

fix(minimax): correct API base URLs to api.minimax.io - #2924

Merged
POWERFULMOVES merged 4 commits into
mainfrom
fix/minimax-api-base
Sep 7, 2026
Merged

POWERFULMOVES merged 4 commits into
mainfrom
fix/minimax-api-base

Conversation

@POWERFULMOVES

Copy link
Copy Markdown
Owner

Summary

  • provider_catalog.yaml: api.minimaxi.chatapi.minimax.io
  • tensorzero.minimax.toml: api.minimax.chatapi.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/models probe.

Verification

  • Live API probe: model list returns MiniMax-M2.7/M2.1 ✅

Note: provider_catalog.yaml line 482-ish api_base only; no other fields touched.

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).
@chatgpt-codex-connector

chatgpt-codex-connector Bot commented Sep 4, 2026

Copy link
Copy Markdown

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review Status Commit Review trigger
📝 Code Review Completed 2026-09-04T14:44:42.896519Z 23a4427 PR opened
ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

@coderabbitai

coderabbitai Bot commented Sep 4, 2026

Copy link
Copy Markdown
Contributor

Important

Review skipped

Auto reviews are limited based on label configuration.

🏷️ Required labels (at least one) (1)
  • coderabbit

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Team

Run ID: a5cff6dc-e6ee-4799-a488-186d92026f4d

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@github-actions github-actions Bot added the config pmoves/config(s)/ changes label Sep 4, 2026
POWERFULMOVES pushed a commit that referenced this pull request Sep 5, 2026
…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
POWERFULMOVES added a commit that referenced this pull request Sep 5, 2026
…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>
@POWERFULMOVES
POWERFULMOVES merged commit 21789f2 into main Sep 7, 2026
27 checks passed
@POWERFULMOVES
POWERFULMOVES deleted the fix/minimax-api-base branch September 7, 2026 20:50
POWERFULMOVES added a commit that referenced this pull request Sep 9, 2026
…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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

config pmoves/config(s)/ changes

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant