[serve] Add warning for env vars with no RAY_SERVE_ prefix

[axreldable]

Why are these changes needed?

• Introduce a warning for Ray Serve environment variables. Since version 2.50.0 the prefix RAY_SERVE_ will be required for all env variables. Warning message contains an instruction for users to change wrong env names.

Commands:

ray start --head
serve config

Output:

bash$ serve config
~/ray/python/ray/serve/_private/constants.py:57: FutureWarning: Got unexpected environment variable name `MAX_DEPLOYMENT_CONSTRUCTOR_RETRY_COUNT`! Starting from version `2.50.0`, all environments variables related to `Ray Serve` will require prefix `RAY_SERVE_`. Change the name to start with the `RAY_SERVE_` prefix.
  MAX_DEPLOYMENT_CONSTRUCTOR_RETRY_COUNT = get_env_int(
~/ray/python/ray/serve/_private/constants.py:63: FutureWarning: Got unexpected environment variable name `MAX_PER_REPLICA_RETRY_COUNT`! Starting from version `2.50.0`, all environments variables related to `Ray Serve` will require prefix `RAY_SERVE_`. Change the name to start with the `RAY_SERVE_` prefix.
  MAX_PER_REPLICA_RETRY_COUNT = get_env_int("MAX_PER_REPLICA_RETRY_COUNT", 3)
~/ray/python/ray/serve/_private/constants.py:104: FutureWarning: Got unexpected environment variable name `REQUEST_LATENCY_BUCKETS_MS`! Starting from version `2.50.0`, all environments variables related to `Ray Serve` will require prefix `RAY_SERVE_`. Change the name to start with the `RAY_SERVE_` prefix.
  get_env_str("REQUEST_LATENCY_BUCKETS_MS", ""), DEFAULT_LATENCY_BUCKET_MS
~/ray/python/ray/serve/_private/constants.py:108: FutureWarning: Got unexpected environment variable name `MODEL_LOAD_LATENCY_BUCKETS_MS`! Starting from version `2.50.0`, all environments variables related to `Ray Serve` will require prefix `RAY_SERVE_`. Change the name to start with the `RAY_SERVE_` prefix.
  get_env_str("MODEL_LOAD_LATENCY_BUCKETS_MS", ""), DEFAULT_LATENCY_BUCKET_MS
~/ray/python/ray/serve/_private/constants.py:121: FutureWarning: Got unexpected environment variable name `MAX_CACHED_HANDLES`! Starting from version `2.50.0`, all environments variables related to `Ray Serve` will require prefix `RAY_SERVE_`. Change the name to start with the `RAY_SERVE_` prefix.
  MAX_CACHED_HANDLES = get_env_int_positive("MAX_CACHED_HANDLES", 100)
~/ray/python/ray/serve/_private/constants.py:125: FutureWarning: Got unexpected environment variable name `CONTROLLER_MAX_CONCURRENCY`! Starting from version `2.50.0`, all environments variables related to `Ray Serve` will require prefix `RAY_SERVE_`. Change the name to start with the `RAY_SERVE_` prefix.
  CONTROLLER_MAX_CONCURRENCY = get_env_int_positive("CONTROLLER_MAX_CONCURRENCY", 15_000)
~/ray/python/ray/serve/_private/constants.py:237: FutureWarning: Got unexpected environment variable name `SERVE_REQUEST_PROCESSING_TIMEOUT_S`! Starting from version `2.50.0`, all environments variables related to `Ray Serve` will require prefix `RAY_SERVE_`. Change the name to start with the `RAY_SERVE_` prefix.
  or get_env_float("SERVE_REQUEST_PROCESSING_TIMEOUT_S", 0.0)
No configuration was found.

• Update get_env_str and get_env_bool to use internal _get_env_value + update type hints (after Gemini review)

Related issue number

Closes #55453

Checks

• I've signed off every commit(by using the -s flag, i.e., git commit -s) in this PR.
• I've run scripts/format.sh to lint the changes in this PR.
• I've included any doc changes needed for https://docs.ray.io/en/master/.
  • I've added any new APIs to the API Reference. For example, if I added a
    method in Tune, I've added it in doc/source/tune/api/ under the
    corresponding .rst file.
• I've made sure the tests are passing. Note that there might be a few flaky tests, see the recent failures at https://flakey-tests.ray.io/
• Testing Strategy
  • Unit tests
  • Release tests
  • This PR is not tested :(

[gemini-code-assist]

Code Review

This pull request introduces a warning for environment variables used in Ray Serve that do not have the RAY_SERVE_ prefix. This is a good step towards standardizing environment variable names. However, the current implementation has a few issues.

First, the implementation is incomplete. The warning is only triggered for functions that use _get_env_value internally (like get_env_int, get_env_float). The get_env_str and get_env_bool functions do not use _get_env_value and thus will not trigger the warning. This should be fixed to ensure all environment variables are checked.

Second, there is a bug in how the warning's stacklevel is determined. It's hardcoded, which will cause warnings to point to the wrong location in the code for some call stacks.

I've added specific comments with suggestions for fixing these issues, improving the implementation, and adding necessary test coverage.

[axreldable]

/gemini

[gemini-code-assist]

Hi @axreldable! It looks like you might have intended to trigger a code review. If so, please use the command /gemini review in a new comment. You can find more details on available commands by typing /gemini help.

[axreldable]

/gemini help

[gemini-code-assist]

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

[axreldable]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces a FutureWarning for Ray Serve environment variables that are missing the RAY_SERVE_ prefix, which will be required in a future version. The implementation correctly centralizes the warning logic in a new _name_warning function called from the _get_env_value helper. The changes also refactor existing get_env_* functions to use this central helper, ensuring consistent behavior. The tests have been properly updated to account for the new warning.

I have two suggestions for improvement. First, the stacklevel for the warning is hardcoded, which can lead to incorrect source line reporting for warnings from nested helper functions. Second, I've identified a pre-existing type hint inaccuracy in get_env_str that this PR's refactoring makes more apparent. Addressing these points will enhance the code's correctness and the overall developer experience.

[axreldable]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces a helpful warning for Ray Serve environment variables that are missing the RAY_SERVE_ prefix, which will be required in a future version. The changes are well-implemented, refactoring existing utility functions to consistently apply the new warning. The accompanying test updates are also correct and verify the new behavior. I have one minor suggestion to improve code style.

[axreldable]

Hi @abrarsheikh !

Could you please check this?

[abrarsheikh]

Here’s the approach I’d suggest:

1. Create an allowlist of existing environment variables that currently violate the naming convention.
2. Introduce corrected versions of these variables with valid names, while keeping the old ones temporarily supported.
3. Warn users that the old variable names will be deprecated and removed in the next major release (Serve 3.0.0). Encourage them to update their configs proactively.
4. Enforce strict validation going forward: any new environment variables not in the allowlist must comply with the naming convention; otherwise they should fail the check.

We can’t immediately enforce the renaming of existing variables, since that would be too disruptive. These variables have been around for a long time, and forcing a change would risk breaking production setups when users upgrade.