fix(async): publish weights before the next fully-async drain

[nanjiangwill]

Summary

• preserve the existing next-rollout lookahead for ordinary pipelined async training
• on fully-async update steps, publish the new weights before starting the next consumer drain
• retain fully-async lookahead on steps where the weight version cannot change

Why

The fully-async rollout function owns a persistent producer that continues generating independently of get(). The driver still inherited the older finite-batch pipeline behavior: it started the next get() before training and waited for that batch before publishing weights.

Under fully async, get() is a consumer drain rather than the lifetime of generation. Waiting for it delays publication, does not quiesce the persistent producer, and makes the drain capture the previous weight version for staleness filtering.

This change separates those semantics without depending on an endpoint or transfer protocol. The weight-update protocol remains responsible for pausing, updating, versioning, and resuming engines.

Tests

• ordinary async still finishes its in-flight next rollout before publication
• fully async with an update every step starts the next drain after publication
• fully async preserves safe lookahead between less-frequent weight updates

Tested with:

pytest -q tests/fast/test_train_async.py
pre-commit run --files train_async.py tests/fast/test_train_async.py

[claude]

Claude Code Review

This pull request is from a fork — automated review is disabled. A repository maintainer can comment @claude review to run a one-time review.

[Shi-Dong]

@claude review always

[claude]

Nothing blocking. The comments below are optional suggestions. There is no need to push a fix for them before merging.

[Shi-Dong]

Reviewed with local execution at c4f919f: 7/7 driver tests, with an exact fail-before on base (the two new fully-async ordering tests fail; the ordinary pipeline test passes unchanged). Re-verified after #3587 landed on main: the merge is conflict-free, and on the combined tree the driver tests (7/7) and the new argument-resolution tests (5/5) pass — the path-without-flag scenario from the review thread is closed by #3587 (path selection now enables the mode), so that thread can be resolved with a pointer to it.