[F] simplify flush_cache: drop retry loop (vLLM /reset_prefix_cache always returns 200)

[aoshen02]

Summary

Originally this PR ported slime #1953 (log non-200 on flush_cache + back off). On review that change is inert on vLLM: vime's flush_cache posts to vLLM's /reset_prefix_cache, whose handler always returns Response(status_code=200) (it ignores the internal success/False bool) and gives no busy signal. So the 60× retry loop, the non-200 log, and the TimeoutError can never fire.

This PR instead drops the loop entirely and collapses flush_cache to a single best-effort POST + raise_for_status().

Why this diverges from slime #1953 (intentional, maintainer-approved)

slime's loop is a real drain barrier: sglang /flush_cache returns 400 while the engine has pending requests, so slime retries until the engine drains. vLLM has no equivalent — /reset_prefix_cache 200s unconditionally, and vime's pause uses mode="keep" (it never uses flush as a drain barrier; colocate drains via /sleep). SkyRL (same vLLM keep-mode flow) likewise does a single reset_prefix_cache call with no loop.

Diff

flush_cache: 22-line retry loop → single POST /reset_prefix_cache?reset_running_requests=false&reset_external=false + raise_for_status(). py_compile + ruff clean; time import still used elsewhere.

[gemini-code-assist]

Code Review

This pull request adds logging and a 1-second delay when the vLLM prefix cache reset fails (non-200 status code). The review feedback suggests changing the log level from info to warning, truncating the response text to prevent log flooding, and refactoring the retry logic to avoid infinite retries on non-retriable 4xx client errors.

[gemini-code-assist]

Log Level and Potential Log Flooding

1. Log Level: The message is logged as logger.info, but it represents an error condition ("Error resetting vLLM prefix cache"). It should be logged as logger.warning or logger.error to make it easier to monitor and filter in production logs.
2. Log Flooding / Truncation: Logging the entire response.text without truncation can lead to severe log flooding or high memory usage if the server returns a very large HTML/JSON error response (e.g., from Nginx, a proxy, or a core dump). It is safer to truncate response.text to a reasonable limit (e.g., 1000 characters).

Suggested change

	logger.info("Error resetting vLLM prefix cache: HTTP %s %r", response.status_code, response.text)
	logger.warning("Error resetting vLLM prefix cache: HTTP %s %r", response.status_code, response.text[:1000])

[gemini-code-assist]

Infinite Retry on Non-Retriable 4xx Client Errors

If the server returns a 4xx client error (such as 404 Not Found if the endpoint is unsupported/disabled, or 400 Bad Request), retrying 60 times is futile and unnecessarily blocks the execution for up to 60 seconds.

However, because of the generic except Exception as e: block on line 780, any standard exception raised inside the try block (like response.raise_for_status()) will be caught and retried anyway.

To improve robustness and fail fast, consider refactoring the exception handling to distinguish between retriable and non-retriable errors, or specifically check for 4xx status codes and propagate the error immediately without retrying.

[CalvinXKY]

logger.info("Error -> logger.warning is better?

[aoshen02]

Dropping per maintainer call. #137's only change was logging a non-200 from /reset_prefix_cache + a 1s backoff — but vLLM's /reset_prefix_cache always returns 200 (the handler ignores the internal success/False bool), so that branch is dead code on vLLM. SkyRL (same vLLM keep-mode practice) doesn't carry it either, and slime #1953's actual value (retry-until-drained, which relies on sglang's 400-while-busy) does not translate to vLLM's endpoint. flush_cache's existing loop + exception-retry on main is unaffected.

[princepride]

LGTM