Add Qwen3 / Qwen3-Coder support to swe-agent-v2 example (ROCm-safe)

[lizamd]

• run.py: parameterize SGLang/TITO parsers (GLM-4.7-Flash defaults unchanged); set RAY_EXPERIMENTAL_NOSET_HIP_VISIBLE_DEVICES only under torch.version.hip so it is a no-op on NVIDIA (CUDA device management unchanged there)
• run-qwen3-swe.py: thin Qwen3/Qwen3-Coder launcher reusing run.py; --coder uses Qwen3-Coder-30B-A3B-Instruct (rope_theta=1e7 via MODEL_ARGS_ROTARY_BASE)
• server.py: add the missing task-agnostic Harbor /run server (README references it; closely related to the codecontests server in Multi-turn RL on CodeContests on AMD MI35x #1603) plus turns/tool_calls metrics so agent/turns_mean populates
• README: Qwen3/Coder usage and ROCm prerequisites

[gemini-code-assist]

Code Review

This pull request introduces support for Qwen3 and Qwen3-Coder models in the Agent V2 pipeline, including documentation, a dedicated launcher script, and configuration updates for ROCm/AMD environments. It also adds a FastAPI server wrapping Harbor for generalized agent-environment orchestration. Feedback on the changes highlights a potential path traversal vulnerability in the server's path validation, a potential TypeError during reward extraction, and a potential AttributeError when checking torch.version.hip on environments with older PyTorch installations.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

The path traversal check uses startswith on a string representation of the path (task_path.startswith(tasks_dir_str)). This is vulnerable to partial path traversal (e.g., if tasks_dir is /root/harbor_tasks, a raw_id of ../harbor_tasks_secret resolves to /root/harbor_tasks_secret, which starts with /root/harbor_tasks and bypasses the check). Using Path.is_relative_to is much safer and prevents this vulnerability.

        try:
            resolved_task_path = (tasks_dir / raw_id).resolve()
            if not resolved_task_path.is_relative_to(tasks_dir):
                logger.error(f"Path traversal blocked: {raw_id!r}")
                return _error_response("InvalidInstanceId")
            task_path = resolved_task_path
        except Exception:
            logger.error(f"Invalid path resolution: {raw_id!r}")
            return _error_response("InvalidInstanceId")

        # Case-insensitive fallback: the SWE-Gym adapter lowercases task dir names
        # (Docker repo names must be lowercase), but dataset instance_ids keep the
        # original case (e.g. Project-MONAI__MONAI-1030). Try the lowercased dir if
        # the exact-case one is absent so those instances aren't TaskNotFound.
        if not task_path.exists() and raw_id != raw_id.lower():
            try:
                lower_path = (tasks_dir / raw_id.lower()).resolve()
                if lower_path.is_relative_to(tasks_dir) and lower_path.exists():
                    logger.info(f"Resolved {raw_id!r} -> lowercase task dir {raw_id.lower()!r}")
                    task_path = lower_path
            except Exception:
                pass

        if not task_path.exists():
            logger.error(f"Task directory not found: {task_path}")
            return _error_response("TaskNotFound")

[gemini-code-assist]

If rewards contains a "reward" key with a None value (e.g., {"reward": None}), rewards.get("reward", ...) will return None, causing float(None) to raise a TypeError. Handling this defensively ensures the server won't crash during reward extraction.

    vr = getattr(result, "verifier_result", None)
    if vr is None:
        return 0.0, {}
    rewards = getattr(vr, "rewards", None) or {}
    reward_val = rewards.get("reward")
    if reward_val is None:
        reward_val = next(iter(rewards.values()), 0.0)
    try:
        reward = float(reward_val) if reward_val is not None else 0.0
    except (TypeError, ValueError):
        reward = 0.0
    return reward, dict(rewards)

[gemini-code-assist]

Directly accessing torch.version.hip can raise an AttributeError on environments with custom or older PyTorch installations where the hip attribute is not defined. Using getattr is safer and adheres to defensive programming practices.

Suggested change

	import torch
	if torch.version.hip:
	extra_env_vars["RAY_EXPERIMENTAL_NOSET_HIP_VISIBLE_DEVICES"] = "1"
	import torch
	if getattr(torch.version, "hip", None):
	extra_env_vars["RAY_EXPERIMENTAL_NOSET_HIP_VISIBLE_DEVICES"] = "1"

[lizamd]

CI infra flake: CPU test stages fail at conftest import when HuggingFace can't serve Qwen/Qwen3-0.6B

The stage-a-cpu / stage-b-cpu failures on this PR are unrelated to the diff (which only touches examples/experimental/swe-agent-v2/; Run pre-commit is green). Root cause is a pre-existing test-collection issue.

Symptom — pytest aborts during collection with exit code 4:

ImportError while loading conftest '.../tests/conftest.py'.
...
miles/utils/test_utils/mock_tools.py:144: in <module>
    _TOKENIZER = load_tokenizer("Qwen/Qwen3-0.6B", trust_remote_code=True)
...
E   OSError: Can't load tokenizer for 'Qwen/Qwen3-0.6B'.

Root cause — miles/utils/test_utils/mock_tools.py:144 loads the Qwen/Qwen3-0.6B tokenizer from HuggingFace at module-import time. It's pulled into every CPU test run via tests/conftest.py → tests/fast/fixtures/generation_fixtures.py:21 (from miles.utils.test_utils import mock_tools). Because the fetch happens at import, a single failed HF download aborts all collection (exit 4), not just tests that use the tokenizer.

Intermittent, not deterministic (→ HF rate-limit / transient fetch) — within the same commit 33a95a1, stage-a-cpu (2) passed while stage-a-cpu (0)/(1)/(3) and stage-b-cpu failed with the tokenizer error; all CPU shards passed earlier on 7d887f4. Consistent with anonymous HF rate-limiting when shards fetch concurrently.

Suggested fixes (maintainer side):

1. Add an HF_TOKEN secret to the CPU test workflow (authenticated pulls avoid the anonymous rate limit), and/or
2. actions/cache on ~/.cache/huggingface so shards don't each re-download, and/or
3. Vendor the small Qwen/Qwen3-0.6B tokenizer as a test asset + HF_HUB_OFFLINE=1.
   Optionally make mock_tools._TOKENIZER lazy so a plain import no longer performs a network call (limits blast radius to tests that actually need it).

[yushengsu-thu]

create an examples/experimental/swe-agent-v2-amd and put your files into in

[lizamd]

create an examples/experimental/swe-agent-v2-amd and put your files into in

@yushengsu-thu done — moved the AMD/Qwen3 work into examples/experimental/swe-agent-v2-amd/ and reverted examples/experimental/swe-agent-v2/ to its base state (no shared-file edits now).

The new dir is self-contained: it has its own run.py (the generalized parser config + ROCm HIP_VISIBLE_DEVICES handling), plus run-qwen3-swe.py, server.py, and a standalone README.md. It also carries copies of the runtime deps generate.py / swe_agent_function.py so it runs without touching the shared example — happy to reference the shared modules instead if you'd prefer no duplication.

(FYI the earlier Gemini findings were already addressed in an earlier commit. The remaining CI red is the pre-existing Qwen/Qwen3-0.6B tokenizer-fetch flake I noted above, unrelated to this diff.) PTAL 🙏