[serve] Call _is_router_running_in_separate_loop() in shutdown_async

[HrushiYadav]

Why are these changes needed?

DeploymentHandle.shutdown_async checks _is_router_running_in_separate_loop without calling it:

# handle.py, shutdown_async()
if self._is_router_running_in_separate_loop:   # missing ()
    await asyncio.wrap_future(shutdown_future)
else:
    await shutdown_future

_is_router_running_in_separate_loop is a method (defined on _DeploymentHandleBase), so referencing it without () evaluates a bound-method object, which is always truthy. shutdown_async therefore always takes the asyncio.wrap_future(...) branch.

When the router runs in the same event loop, self._router.shutdown() returns an asyncio.Future, and asyncio.wrap_future() only accepts a concurrent.futures.Future — so it raises TypeError instead of awaiting the future.

The synchronous shutdown() a few lines above already calls the method correctly (self._is_router_running_in_separate_loop()), as do the other call sites in the file. This just brings shutdown_async in line.

The fix is a one-character change (add ()), plus unit tests covering both the same-loop and separate-loop paths.

Related issue number

N/A — found by inspection.

Checks

• I've signed off every commit (DCO).
• I've run ruff on the changed files.
• I've added unit tests that exercise both branches of the fixed check.

[gemini-code-assist]

Code Review

This pull request fixes a bug in DeploymentHandle.shutdown_async where _is_router_running_in_separate_loop was evaluated as a property instead of being called as a method, which caused it to always evaluate to True. Unit tests have been added to cover both same-loop and separate-loop shutdown scenarios. The feedback suggests using the real InitHandleOptions dataclass instead of a mock in the test helper to improve robustness and type safety.

[gemini-code-assist]

Since InitHandleOptions is a simple dataclass and is already imported in this file, we can use the real class instead of a Mock. This is more robust, type-safe, and avoids unnecessary mocking of data structures.

Suggested change

	handle.init_options = Mock(_run_router_in_separate_loop=run_in_separate_loop)
	handle.init_options = InitHandleOptions(_run_router_in_separate_loop=run_in_separate_loop)

[github-actions]

This pull request has been automatically marked as stale because it has not had
any activity for 14 days. It will be closed in another 14 days if no further activity occurs.
Thank you for your contributions.

You can always ask for help on our discussion forum or Ray's public slack channel.

If you'd like to keep this open, just leave any comment, and the stale label will be removed.

[HrushiYadav]

Keeping this active. Small fix: _is_router_running_in_separate_loop was being checked as a property instead of being called, so shutdown_async took the wrong path. It's green and ready. @abrarsheikh @eicherseiji would either of you be able to take a quick look?

[abrarsheikh]

ping me when the build passes

[HrushiYadav]

@abrarsheikh the premerge failure looks like an infra issue in the build fleet, not this change. This PR only touches two python files (serve/handle.py and a unit test), so it cannot affect the wanda build steps that failed here, which are all C++ core, Java, wheel, and jar compiles. They failed on both the initial run and the retry, and no serve or python test actually ran since they were all still waiting on build artifacts. buildkite/microcheck and buildkite/release both passed on the same commit. Could you re-trigger premerge when you get a chance?