Skip to content

[sandbox] feat: discover external provider modules - #238

Open
tongyx361 wants to merge 1 commit into
verl-project:mainfrom
tongyx361:pr/sandbox-plugin-discovery
Open

tongyx361 wants to merge 1 commit into
verl-project:mainfrom
tongyx361:pr/sandbox-plugin-discovery

Conversation

@tongyx361

@tongyx361 tongyx361 commented Sep 29, 2026 •

Copy link
Copy Markdown
Contributor

Summary

External sandbox providers currently require modifying the built-in provider table. Add module discovery through UNI_AGENT_SANDBOX_PLUGINS so separately installed providers can register themselves.

Changes

  • Load comma-separated module names when resolving an external provider.
  • Reserve built-in names and preserve import failures across retries, cleaning stale registrations from failed imports.
  • Document worker configuration and test discovery, retry behavior, and built-in name protection.

Validation

  • PYTHONPATH=.:verl uv run --no-project --python /usr/bin/python python -m pytest -q tests/uni_agent/sandbox/test_sandbox_provider_discovery_on_cpu.py tests/uni_agent/sandbox/test_exec_error_policy.py: 34 passed. Tests used the runtime interpreter with Uni-Agent and the pinned public verl gitlink explicitly selected.
  • pre-commit run --all-files --show-diff-on-failure: passed.

Internal validation and benefit

The integration use case is a separately installed sandbox provider that can be selected without adding provider code or dependencies to the built-in registry. No isolated internal latency, throughput or capacity benefit has been measured for plugin discovery itself. Validation for this PR is the discovery, import-failure/retry and built-in-name protection coverage listed above; no internal provider implementation or infrastructure is included.

Compatibility

Built-in providers keep lazy loading. External modules must be installed and configured on each worker; no migration is needed for existing configurations. Provider names reserved by built-in modules cannot be replaced. This is a standalone extension without a linked issue.

Checklist

  • The PR is focused and explains why no issue is needed.
  • The title follows the owning-layer format.
  • Behavior is covered by tests; skipped validation is stated above.
  • User-facing configuration and behavior changes are documented where applicable.
  • Compatibility and migration requirements are documented.
  • Logs, fixtures, and examples contain no credentials or private data.
  • pre-commit run --all-files --show-diff-on-failure passes.

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