[core] Improving the error handling for @ray.remote and @ray.method with num_returns.

[KeeProMise]

Description

There are a few inconsistencies in the ray.remote and ray.method public APIs that need to be fixed and will improve user experience.

@ray.remote and @ray.method decorators should fail fast and return an error if num_returns='streaming' or num_returns='dynamic', but the python function is not a generator function.

@ray.method decorator should fail fast and return an error if num_returns is < 0.

Related issues

see: https://github.com/ray-project/ray/issues/59274

Additional information

Optional: Add implementation details, API changes, usage examples, screenshots, etc.

[edoakes]

@israbbani

[KeeProMise]

@KeeProMise thank you for the contribution. All of the input validation logic is in ray_option_utils.py. Can you PTAL at that file and make the change there?

Hi @israbbani Thank you for taking the time to review. PTAL.

[KeeProMise]

Hi @israbbani @edoakes if you have time, please help to take a look at this PR, thanks!

[KeeProMise]

I think we need to rethink the approach here a little bit. Please take the time to review the code for the decorators and let's design a wholistic solution.

1. If num_returns is streaming or dynamic, fail fast with an error.
2. If num_returns is < 0, fail fast with an error.

The logic for validation should be in one place. it's identical for @ray.remote and @ray.method. It should use/extend existing logic that's already in place for validation inside ray_option_utils.py.

Let's also add some tests for the decorators that validate the logic. You can create a new test file for each decorator and test them directly.

Hi @israbbani PTAL. According to the logs, the failed tests should be unrelated to my modifications.

[KeeProMise]

Hi @israbbani @edoakes All tests passed. if you have time, please help to take a look at this PR, thanks!