[serve] Change test_controller_recovery logging config condition

[akyang-anyscale]

Why are these changes needed?

This changes the test condition to actually check for debug and json logs after controller recovers. The specific access log format is checked in test_logging.py

Related issue number

Checks

• I've signed off every commit(by using the -s flag, i.e., git commit -s) in this PR.
• I've run pre-commit jobs to lint the changes in this PR. (pre-commit setup)
• 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

I've reviewed the change to the logging condition in test_controller_recovery. My feedback focuses on ensuring the test remains precise and clear in its intent. I've provided one comment with a suggestion to improve the test's specificity.

[gemini-code-assist]

This change makes the log check more generic. While this might make the test more robust against log message format changes, it also makes it less precise and potentially confusing.

The original check verified that the access log for the httpx.get request was correctly formatted as JSON. The new check only verifies that any DEBUG level log is present. This has two drawbacks:

1. It no longer tests the request-handling log path. The test now likely relies on DEBUG logs from other sources (like health checks), not the INFO level access log. A regression in access logging could be missed.
2. The httpx.get call is disconnected from the assertion. The test performs an HTTP request, but then checks for a log entry that isn't directly caused by it, which makes the test's intent harder to follow.

If the original check was flaky (e.g., due to log buffering), it would be better to address the root cause of the flakiness.

I recommend restoring a check on the access log to keep the test focused and clear. Here's a suggestion for a robust regex that checks the access log:

Suggested change

	check_log_file, log_file=file_path, expected_regex=['"levelname": "DEBUG"']
	check_log_file, log_file=file_path, expected_regex=['"message": "GET / 200.*"']