[fully_async, reward, docs] fix: skip reward function call when use_task_rewards=False

[kenkenpa2126]

What does this PR do?

Fixes a crash in OPD training when distillation.distillation_loss.use_task_rewards=False and the dataset's data_source is not registered in default_compute_score.

The use_task_rewards flag previously only suppressed the task-reward contribution to the loss (in distillation/losses.py) but did not prevent _compute_score from being invoked in agent_loop.py. When using a custom dataset whose data_source is not registered in the default reward registry, this raised NotImplementedError and crashed training before the first step.

OPD with use_task_rewards=False trains entirely on the distillation loss; invoking the reward function is unnecessary and error-prone with custom datasets.

Checklist Before Starting

• Search for similar PRs. Paste at least one query link here: No related pr found. https://github.com/verl-project/verl/pulls?q=is%3Apr+use_task_rewards, https://github.com/verl-project/verl/pulls?q=is%3Apr+reward+skip+distillation
• Format the PR title as [{modules}] {type}: {description} (This will be checked by the CI)
  • {modules} include fsdp, megatron, veomni, sglang, vllm, rollout, trainer, ci, training_utils, recipe, hardware, deployment, ray, worker, single_controller, misc, perf, model, algo, env, tool, ckpt, doc, data, cfg, reward, fully_async, one_step_off
  • If this PR involves multiple modules, separate them with , like [megatron, fsdp, doc]
  • {type} is in feat, fix, refactor, chore, test
  • If this PR breaks any API (CLI arguments, config, function signature, etc.), add [BREAKING] to the beginning of the title.
  • Example: [BREAKING][fsdp, megatron] feat: dynamic batching

Test

Verified under fully async OPD training with a custom QA dataset (data_source not registered in default_compute_score). Previously crashed at the first distillation step with NotImplementedError; now runs without invoking the reward function when use_task_rewards=False.

API and Usage Example

No API change. Existing config usage:

distillation:
  distillation_loss:
    use_task_rewards: false   # reward function is now skipped entirely

Design & Code Changes

• verl/experimental/agent_loop/agent_loop.py: reads use_task_rewards from distillation config in init (defaults to True when distillation is disabled); wraps _compute_score call with if self.use_task_rewards.
• docs/algo/opd.md: clarifies that use_task_rewards=false skips the reward function invocation entirely, not just the loss contribution.

Checklist Before Submitting

• Read the Contribute Guide.
• Apply pre-commit checks: pre-commit install && pre-commit run --all-files --show-diff-on-failure --color=always
• Add / Update the documentation.
• Add unit or end-to-end test(s) to the CI workflow to cover all the code. If not feasible, explain why:

The fix is a single conditional guard in the agent loop. Testing requires a fully running async OPD stack (rollout server + teacher server + trainer), which is not feasible in CI. Verified by end-to-end training run with a custom dataset.

• Once your PR is ready for CI, send a message in the ci-request channel in the verl Slack workspace. (If not accessible, please try the Feishu group (飞书群).)
• If your PR is related to the recipe submodule, please also update the reference to the submodule commit via git submodule update --remote or cd recipe && git pull origin main.

[gemini-code-assist]

Code Review

This pull request introduces a configuration option 'use_task_rewards' to conditionally skip reward computation ('_compute_score') during agent loop post-processing. This is useful when training with custom datasets that do not have a compatible reward function. The documentation in 'docs/algo/opd.md' has been updated to reflect this behavior. There are no review comments, so we have no feedback to provide.

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.

[wuxibin89]

@kenkenpa2126 Which trainer do you use? In new V1 trainer, rm_scores is still needed to compute advantages even if use_task_rewards=False.
https://github.com/verl-project/verl/blob/main/verl/trainer/ppo/v1/trainer_base.py#L450-L452

[kenkenpa2126]

@wuxibin89
Thanks for the review! To clarify: I was using FullyAsyncTrainer (experimental/fully_async_policy), not the V1 trainer. In my actual experiment I had a custom compute_score returning 0.0 unconditionally, so _compute_score() was always called and rm_scores was always populated. This means the use_task_rewards=False code path I added was never actually exercised — the fix and the validation were misaligned.

You're right that rm_scores must always be present. Addressed this in a follow-up commit (e242dae) by setting reward_score = 0.0 in the else branch, and added a CPU unit test (c2d8712).