increase timeout for test_initial_replica tests

[harshit-anyscale]

• test_target_capacity windows test is failing, possibly because we have put up a short timeout of 10 seconds, increasing it to verify whether timeout is an issue or not.

[gemini-code-assist]

Code Review

This pull request increases the timeout for a test in test_initial_replica_tests to address a potential flakiness issue on Windows. The change is straightforward and reasonable. I've added a suggestion to use a named constant for the timeout value to improve code maintainability.

[gemini-code-assist]

To improve readability and maintainability, it's better to define this timeout value as a named constant at the top of the file or test class, for example INITIAL_REPLICA_TEST_TIMEOUT_S = 30. This makes it easier to understand the purpose of the timeout and to adjust it in the future if needed, especially since other timeouts are used in this file.

Suggested change

	timeout=30,
	timeout=30, # Consider defining this as a constant, e.g., INITIAL_REPLICA_TEST_TIMEOUT_S

[cursor]

Bug: Inconsistent Timeout Updates in Replicas Test Suite

Inconsistent timeout handling in test_initial_replicas_new_configs. The PR aims to increase timeout to 30 seconds to address Windows test failures, but only the first wait_for_condition call (line 1078) was updated. Two subsequent wait_for_condition calls with check_expected_num_replicas (lines 1103-1109 for "app1" and lines 1110-1116 for "app2") still use the default 10-second timeout. These calls are checking similar replica scaling conditions and are likely to experience the same timeout issues on Windows, making the fix incomplete.

python/ray/serve/tests/test_target_capacity.py#L1102-L1116

ray/python/ray/serve/tests/test_target_capacity.py

Lines 1102 to 1116 in 7ecde7f

	client.deploy_apps(new_config)
	wait_for_condition(
	lambda: serve.status().target_capacity == new_config_target_capacity
	)
	wait_for_condition(
	check_expected_num_replicas,
	deployment_to_num_replicas={
	deployment_name: int(
	initial_replicas * new_config_target_capacity / 100
	)
	},
	app_name="app1",
	)
	wait_for_condition(
	check_expected_num_replicas,

 

---

[zcin]

@harshit-anyscale did you run the windows test to verify the fix

[harshit-anyscale]

@harshit-anyscale did you run the windows test to verify the fix

not right now, this seems to be a brute-force solution to me because the status we were getting is Deploying, but what we want is running, so thought of increasing the timeout first to make it less flakey and less problematic for others. If this works, will do the RCA for this, and take steps

this is sort-of trying a short term solution. let me know if that's okay or else will perform the windows test locally first.

[cursor]

Bug: Incomplete timeout propagation in test retries

The timeout increase to 30 seconds is only applied to the first wait_for_condition call in test_initial_replicas_new_configs, but two similar calls later in the same test (around lines 1103 and 1111) still use the default 10-second timeout. This incomplete fix means the test can still fail on Windows due to timeouts in those later assertions, defeating the purpose of this PR.