chore: sync main → staging (auto, ff to d35a2420) - #2263
Merged
Conversation
staging → main: auto-promote fcd87b9
HongmingWang-Rabbit
pushed a commit
that referenced
this pull request
Jun 12, 2026
…2263) The staging SaaS E2E provisioned its claude-code canary with the BARE id `MiniMax-M2`. The deployed staging tenant ws-server's compiled model registry lags source, so validateRegisteredModelForRuntime returns HTTP 400 on the bare id at workspace-create. The sibling Platform Boot job, on the SAME image, succeeds with the NAMESPACED `moonshot/kimi-k2.6` — only the id form differs (deploy-skew, internal#718; NOT flaky). Harness-side fix: switch the claude-code MiniMax default from bare `MiniMax-M2` to the COLON-namespaced `minimax:MiniMax-M2.7`. Crucially this is the colon (BYOK) form, NOT the slash/platform form `minimax/MiniMax-M2.7` the issue floated: the canary injects E2E_MINIMAX_API_KEY (BYOK), so the #1994 byok-not-platform guard asserts provider_selection=minimax. The colon form stays in the BYOK `minimax` arm (providers.yaml:851 → provider=minimax, passes the guard); the slash form resolves to provider=platform and would trip it. Mirrors how the proven-working kimi BYOK colon-form is registered. Changed both the operator-override default in e2e-staging-saas.yml (which sets E2E_MODEL_SLUG and wins over pick_model_slug) and the pick_model_slug fallback in lib/model_slug.sh, plus the pinned unit-test expectations. Also: widen the known-answer A2A POST retry grep to include the Cloudflare-shaped literal `error code: 502/504` token, matching the cold-start PONG probe and delegation loops. A single un-retried edge 502 right after a healthy round-trip (Platform Boot, task 268859) fell through to break and failed the gate on the first attempt. Bounded by the existing 6-attempt/sleep-10 loop — no new sleep-as-fix. NOTE: harness-side only. The durable fix is promoting the staging tenant ws-server runtime image to a build whose compiled registry includes the bare id. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
HongmingWang-Rabbit
pushed a commit
that referenced
this pull request
Jun 12, 2026
…ed minimax id + match edge-502 retry' (#2274) from fix/2263-staging-canary-namespaced-model into main
HongmingWang-Rabbit
pushed a commit
that referenced
this pull request
Jun 12, 2026
…fered runtime×provider gated (keyless, required-lane)
Closes the provider-routing-correctness coverage hole identified in the
regression-coverage audit: many offered (runtime → provider) pairs — hermes's
17 name-only BYOK arms, claude-code's zai/deepseek/xiaomi-mimo, openclaw's
byok-openai/byok-minimax/groq/openrouter/custom, codex's byok-minimax, etc. —
are pure prefix-routing resolved by DeriveProvider(runtime, modelId) and had
ZERO test. A regression in the routing table (wrong provider, dropped arm, bad
regex) shipped silently and wedged tenant agents at boot.
DeriveProvider + ModelPrefixMatch resolve a model id to a provider with NO
upstream call — fully keyless — so the ENTIRE offered routing table is gateable
in the REQUIRED CI / all-required lane with zero secrets.
derive_provider_matrix_test.go is SSOT-DRIVEN (not hardcoded): it iterates
LoadManifest().Runtimes (the same registry production reads) and, for every
runtime × every offered model/provider arm, asserts (a) DeriveProvider resolves
to the EXACT expected provider (computed from the SSOT), (b) the (runtime, model)
is registration-valid (the validateRegisteredModelForRuntime predicate), and
(c) no offered id silently resolves to the wrong arm or falls through.
- exact-listed arms: every model id iterated off the SSOT, expected provider
computed from native declaration order (first-declared wins the codex/
anthropic "one id, two auth arms" shape). A newly-added model is auto-covered.
- name-only arms (zero models, pure prefix BYOK): each probed with a
representative BYOK id its regex must own. The matrix REQUIRES a representative
for every name-only arm in the SSOT — "added an arm, forgot routing/sample"
fails RED. A dead representative (provider removed) also fails RED.
Coverage: 5 runtimes, 43 (runtime×provider) arms across 29 distinct providers,
53 exact-listed (runtime×model) assertions + 29 name-only BYOK routing probes.
Known-tricky forms pinned as explicit assertions so a regression names its class:
the #2263/#2274 colon-vs-slash-vs-bare MiniMax triple on claude-code (bare→minimax,
slash→platform, colon→unregistered), openai-namespaced-rejected-on-claude-code
(#2265 class), groq→groq, hermes anthropic//gemini//openai://minimax: →
byok-* (NOT platform — cp#529 billing safety), codex gpt default→openai-subscription
vs OPENAI_API_KEY→openai-api, google-adk platform: vs bare gemini.
Watch-it-fail proven: adding minimax:MiniMax-M2.7 to claude-code's platform arm
(pointing the colon BYOK form at platform) reds the matrix naming the exact
mismatch ("= platform, want an unregistered/unrouteable ERROR"); reverted → green.
go build ./... and go vet ./internal/providers/ clean.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
HongmingWang-Rabbit
pushed a commit
that referenced
this pull request
Jun 12, 2026
…n (internal#718 UNREGISTERED) The staging full-SaaS e2e provisioned a claude-code parent workspace with the colon-namespaced model id `minimax:MiniMax-M2.7` (from tests/e2e/lib/model_slug.sh), which is INTENTIONALLY unregistered for the claude-code runtime: the claude-code adapter cannot strip the `minimax:` prefix, so create-validation (provider-registry SSOT, internal#718) rejects it 422 UNREGISTERED_MODEL_FOR_RUNTIME. Evidence: real staging run job 295075 (main 797351b) failed at "5/11 Provisioning parent workspace" with: {"code":"UNREGISTERED_MODEL_FOR_RUNTIME","error":"model \"minimax:MiniMax-M2.7\" is not a registered model for runtime \"claude-code\"; pick one of the runtime's registered models (provider-registry SSOT, internal#718)"} This 422 is correct, intentional product behavior, pinned by workspace-server/internal/providers/derive_provider_matrix_test.go (the #2263/#2274 colon-vs-slash-vs-bare MiniMax triple): bare "MiniMax-M2.7" -> provider=minimax (BYOK) slash "minimax/MiniMax-M2.7" -> provider=platform colon "minimax:MiniMax-M2.7" -> UNREGISTERED (adapter can't strip minimax:) The bare form is registered in claude-code's `minimax` arm (registry_gen.go:88 Models=[MiniMax-M2,MiniMax-M2.7,MiniMax-M2.7-highspeed, MiniMax-M3]) and derives provider=minimax BYOK via MINIMAX_API_KEY. Test-only fix (zero production code): - tests/e2e/lib/model_slug.sh: claude-code|seo-agent MiniMax-BYOK path now emits the bare registered `MiniMax-M2.7`; rewrote the now-wrong comments that claimed the colon form gives BYOK on claude-code (it doesn't — colon is only the correct BYOK id on openclaw/hermes, which DO strip the prefix). - tests/e2e/test_model_slug.sh: updated the three pins from the colon form to the bare form (claude-code + minimax, both-keys priority, seo-agent). - tests/e2e/test_priority_runtimes_e2e.sh: the live MiniMax arm directly provisioned claude-code with the same colon id (same UNREGISTERED 422 class) — switched to bare `MiniMax-M2.7` and corrected the "registry-skew" framing. - tests/e2e/test_staging_full_saas.sh: corrected a stale diagnostic string. Audit of other arms (no other UNREGISTERED mismatch found): hermes/codex slash `openai/gpt-4o` and google-adk bare `gemini-2.5-pro` and the test_peer_visibility `minimax/MiniMax-M2.7` slash form are all registered for their runtimes per the matrix test; left unchanged. openclaw/hermes colon-minimax is correct (those adapters strip the prefix) and is not emitted by this helper. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Automated fast-forward of
stagingtoorigin/main(d35a2420). Staging has no in-flight commits that diverge from main. Merge queue lands this; no human action needed.This PR is auto-generated by
.github/workflows/auto-sync-main-to-staging.ymlon every push tomain. It exists because this repo'sstagingbranch has amerge_queueruleset that blocks direct pushes — even from the GitHub Actions integration.