Skip to content

chore: guard the v0 legacy bridge against non-renderer training clients - #1613

Merged
mikasenghaas merged 1 commit into
feat/nano-as-v1from
chore/legacy-v0-client-renderer-guard
Jun 10, 2026
Merged

chore: guard the v0 legacy bridge against non-renderer training clients#1613
mikasenghaas merged 1 commit into
feat/nano-as-v1from
chore/legacy-v0-client-renderer-guard

Conversation

@mikasenghaas

@mikasenghaas mikasenghaas commented Jun 10, 2026

Copy link
Copy Markdown
Member

Summary

Hardens the v0 legacy bridge's training client builder (LegacyEnvServer._v0_client).

  • _v0_client hardcoded a v0 renderer (token-in/out) client. That's correct today — prime-rl trains renderer-only (the orchestrator's student and teacher pools both pin train_client_type="renderer", and it isn't a user-config knob).
  • But the v1 ClientConfig is a discriminated union (type="renderers" vs type="openai"/MITO). A MITO config reaching this path would have silently built a renderer client from an OpenAIClientConfig (its missing renderer/renderer_model_name fall back via getattr), doing TITO instead of the requested MITO rather than failing.

Now:

  • Raise a clear ValueError if _v0_client gets a non-renderer config — MITO (chat-completions) training of v0 envs isn't supported, so fail loudly instead of running the wrong inference mode.
  • With the renderer type now guaranteed, read renderer / renderer_model_name / pool_size directly instead of via defensive getattr.

This is the natural seam at which to add real type="openai" dispatch if MITO training of v0 envs is ever enabled.

Verification

  • ruff check --isolated / ruff format --isolated --check clean.
  • _v0_client raises ValueError on an OpenAIClientConfig; a RendererClientConfig flows through unchanged.

Note

Guard LegacyEnvServer._v0_client against non-renderer training clients

Adds a strict isinstance check in _v0_client that raises ValueError when client_config is not a RendererClientConfig. Also replaces getattr-based access with direct attribute reads for renderer_model_name, renderer, and pool_size.

Macroscope summarized aef8445.


Note

Low Risk
Narrow guard in the legacy training path; renderer configs behave as before, with clearer failure for unsupported MITO training.

Overview
LegacyEnvServer._v0_client now requires a RendererClientConfig. If training passes an OpenAIClientConfig (MITO / chat-completions), it raises a ValueError instead of silently building a renderer client with missing fields and running token-in/token-out training.

After the type check, renderer, renderer_model_name, and pool_size are read directly on the config (no getattr fallbacks).

Reviewed by Cursor Bugbot for commit aef8445. Bugbot is set up for automated code reviews on this repo. Configure here.

_v0_client hardcoded a v0 renderer (token-in/out) client. prime-rl trains
renderer-only, so that's correct today, but a MITO (chat-completions,
type="openai") config would have silently built a renderer client and done
the wrong inference mode instead of erroring.

Raise on a non-renderer client config, and now that the type is guaranteed,
read the renderer fields directly instead of via defensive getattr.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@mikasenghaas
mikasenghaas marked this pull request as ready for review June 10, 2026 22:38
@mikasenghaas
mikasenghaas merged commit 1bf7937 into feat/nano-as-v1 Jun 10, 2026
5 checks passed
@macroscopeapp

macroscopeapp Bot commented Jun 10, 2026

Copy link
Copy Markdown
Contributor

Approvability

Verdict: Approved

Small validation change that adds an explicit type guard to the v0 legacy bridge, failing fast with a clear error message when a non-renderer client is passed instead of silently using defaults. This is defensive hardening with limited scope.

You can customize Macroscope's approvability policy. Learn more.

mikasenghaas added a commit that referenced this pull request Jun 10, 2026
…#1615)

The orchestrator drives eval rollouts of v0 envs through the same
LegacyEnvServer (run_rollout/run_group -> _run_v0 -> _v0_client), and eval
uses an OpenAI chat-completions client. The #1613 guard raised on any
non-renderer config, so it broke v0 eval ("MITO ... not supported").

Dispatch on the config type instead: a renderer config (training, TITO)
builds a v0 renderer client; an OpenAI config (eval) builds a v0
chat-completions client.

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
pull Bot pushed a commit to Stars1233/verifiers that referenced this pull request Jun 23, 2026
…ts (PrimeIntellect-ai#1613)

_v0_client hardcoded a v0 renderer (token-in/out) client. prime-rl trains
renderer-only, so that's correct today, but a MITO (chat-completions,
type="openai") config would have silently built a renderer client and done
the wrong inference mode instead of erroring.

Raise on a non-renderer client config, and now that the type is guaranteed,
read the renderer fields directly instead of via defensive getattr.

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
pull Bot pushed a commit to Stars1233/verifiers that referenced this pull request Jun 23, 2026
…PrimeIntellect-ai#1615)

The orchestrator drives eval rollouts of v0 envs through the same
LegacyEnvServer (run_rollout/run_group -> _run_v0 -> _v0_client), and eval
uses an OpenAI chat-completions client. The PrimeIntellect-ai#1613 guard raised on any
non-renderer config, so it broke v0 eval ("MITO ... not supported").

Dispatch on the config type instead: a renderer config (training, TITO)
builds a v0 renderer client; an OpenAI config (eval) builds a v0
chat-completions client.

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant