fix(rust-server): Drain recv_from_rpc in rust-server mode

[MortalHappiness]

Motivation

Closes the "recv_from_rpc is never drained in rust-server mode" TODO item from #29799.

Rank 0's scheduler drains two input channels per event-loop iteration: the tokenizer channel (zmq PULL, scheduler_input_ipc_name) and the rpc channel (zmq DEALER, rpc_ipc_name, used only by the offline sgl.Engine's collective_rpc). SGLANG_RUST_SERVER replaces the first with an in-process ring and has no rpc equivalent, so the second has to keep working in both modes.

The rust branch was added at the top of _pull_raw_reqs and ends in return, which exits the whole function: it bypasses the tokenizer drain (intended) and the rpc drain below it (not intended). The socket is still created and wired into the receiver, but nothing reads it. The reply direction has the mirror problem: process_input_requests tested self.rust_server is not None before isinstance(output, RpcReqOutput), so the zmq reply branch was unreachable, and the Rust egress path it took instead asserts on a rust-minted rid that an rpc request arriving over zmq does not carry.

Modifications

In scheduler_components/request_receiver.py, the early return becomes an if/else, so rust mode bypasses only the tokenizer drain. The rpc loop body is unchanged.

In scheduler.py, process_input_requests now tests isinstance(output, RpcReqOutput) before the rust_server branch, so an rpc reply goes back down the DEALER pair instead of into the Rust egress ring. This is behaviour-preserving in zmq mode: there rust_server is None, so that branch was already reached.

The two are one fix: draining without the reorder would make the first rpc request in rust mode hit the rid assert and take the scheduler down, turning a silent hang into a crash.

Deliberately not changed

• Idle wake-up. In rust mode the idle loop parks on the ring alone, so an rpc frame arriving at an idle scheduler waits out the 1s park timeout. No unified wait exists, since flume exposes no fd and zmq.Poller cannot watch the ring. The delay is bounded and documented in a comment at the drain, and it is negligible for the checkpoint exports that are its only in-tree callers.

Accuracy Tests

N/A

Speed Tests and Profiling

N/A

Checklist

• Format your code according to the Format code with pre-commit.
• Add unit tests according to the Run and add unit tests.
• Update documentation according to Write documentations.
• Provide accuracy and speed benchmark results according to Test the accuracy and Benchmark the speed.
• Follow the SGLang code style guidance.

Review and Merge Process

1. Ping Merge Oncalls to start the process. See the PR Merge Process.
2. Get approvals from CODEOWNERS and other reviewers.
3. Trigger CI tests with comments or contact authorized users to do so.
   • Common commands include /tag-and-rerun-ci, /tag-run-ci-label, /rerun-failed-ci
4. After green CI and required approvals, ask Merge Oncalls or people with Write permission to merge the PR.

---

CI States

Latest PR Test (Base): ❌ Run #30952583076
Latest PR Test (Extra): ❌ Run #30952582600

[gemini-code-assist]

Caution

The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased.

[hnyls2002]

Is this AI-generated code? Too many comments...

[MortalHappiness]

I'll shorter the comments and make the code more self-explantory. Thanks!

[MortalHappiness]

@hnyls2002 comments trimmed. Thanks.

[rainj-me]

@MortalHappiness , Let's review the scenarios that has to send request via rpc, and double check whether we can migrate to rust.

[github-actions]

Thanks @MortalHappiness. Closing this because it is still a draft and has not been updated in 52 days.

Reopen it if the work is still relevant.

Some directories moved recently, so an older branch may need retargeting:
sgl-kernel/ -> python/sglang/kernels/aot/, python/sglang/jit_kernel/
-> python/sglang/kernels/jit/, docs/ -> docs/docs/ (.mdx),
bench_serving.py -> benchmark/serving.py, test/srt/ -> test/registered/.