fix(verl): make request aborts take effect on vLLM < 0.9 (pooling_output compat shim)

[zzzhang (zzzhang1127)]

Summary

Fixes #589.

verl 0.7.x/0.8.x (the range Agent Lightning pins: verl>=0.7.1,<0.9.0) call RequestState.make_request_output with a pooling_output kwarg in both abort paths (abort_all_requests / abort_request). That parameter only exists from vLLM 0.9 on; on vLLM 0.8.5 (the minimum of verl 0.7.1's declared range, and a common companion) the call raises TypeError, which verl's blanket except Exception swallows:

ERROR ... Error aborting requests: RequestState.make_request_output() got an unexpected keyword argument 'pooling_output'

The net effect is that aborts silently do nothing: rollout requests that failed or timed out keep generating inside vLLM while the trainer proceeds to the FSDP update phase. In our production runs this concurrency crashed training with a CUDA illegal memory access in the sampler (apply_top_k_top_p → logits.sort). Full forensics in #589.

What this PR does

• Adds agentlightning/verl/vllm_compat.py with a signature-detecting shim: if the installed vLLM's make_request_output has no pooling_output parameter, wrap it to drop that kwarg. Positional calls from vLLM's own code path are forwarded untouched; on vLLM >= 0.9 (or vLLM absent) the shim is a strict no-op. It is also idempotent (marker attribute prevents double-wrapping).
• Applies it in every Ray worker process by calling it from the existing worker_process_setup_hook (per_rollout_loss.register_in_worker), so it reaches the vLLMHttpServer actor where the abort path runs (verl's actor-level runtime_env only sets env_vars, so the job-level hook is inherited).
• Adds unit tests (tests/verl/test_vllm_compat.py) covering: old-signature patching with both call styles, idempotency, new-signature no-op, and vLLM-absent no-op.

Validation

• 4/4 new unit tests pass.
• Signature detection verified against a real vLLM 0.8.5 install (shim applies) — and the same fix logic has been running in our production GRPO training (verl 0.7.1 + vLLM 0.8.5, TP=2) since the incident: aborts now take effect and the illegal-memory-access crash has not recurred, including steps with timed-out rollouts.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[zzzhang (zzzhang1127)]

@microsoft-github-policy-service agree

[Zhiyuan He (hzy46)]

As suggested in https://github.com/microsoft/agent-lightning/blob/main/scripts/setup_verl.sh, the suggested vllm for verl 0.7.X is 0.12.0, which is well tested.

However we are happy to have this fix, but please remove the test and make agentlightning/verl/vllm_compat.py as simple as possible. Currently agentlightning/verl/vllm_compat.py contains too many comments

[zzzhang (zzzhang1127)]

Thanks for the review, and good point on the recommended vLLM 0.12.0 for verl 0.7.x — we hit this on a 0.8.5 pairing, and the shim stays a strict no-op on any vLLM that already has pooling_output, so it won't affect the recommended setup.

Addressed both requests in 6b6ae9c:

• Removed tests/verl/test_vllm_compat.py.
• Trimmed vllm_compat.py to the essentials — dropped the long docstrings, keeping a single 3-line comment on why the kwarg is stripped. No behavior change.

[Zhiyuan He (hzy46)]

Sure please fix the type check. Then I can merge this PR.

[zzzhang (zzzhang1127)]

Fixed — added # pyright: ignore[reportMissingImports] on the optional vLLM import (matching the repo's existing convention in agentlightning/verl/trainer.py). Type-check should pass now.

[Zhiyuan He (hzy46)]

Merged. Thank you for the contribution.