[tinker] Route uvicorn's access log to a plain handler instead of Rich

[avigyabb]

Stack 1/7. Independent of the rest.

RichHandler renders each access-log record through a rich Table, about 1.5 ms of event-loop CPU per HTTP request. Under rollout load that was 63% of the Tinker API server's CPU: profiling a 4096-sample run showed 12.5 s of its 19.9 s of server CPU inside rich.logging.emit. With a plain StreamHandler for uvicorn.access the same run takes 9.7 s and server throughput goes from 337 to 568 samples/s. Startup and error logging keep the Rich handler.

Measured with the load harness in stack 7/7 (skyrl/benchmarks/load_test_tinker_sampling.py).

Stack (each PR retargets to main as the one below merges)

1. [tinker] Route uvicorn's access log to a plain handler instead of Rich #2160
2. [tinker] Forward samples with aiohttp instead of httpx #2161
3. [tinker] Keep an undelivered sample result alive for the SDK's retry #2162
4. [tinker] Survive completion bursts at the socket layer (accept backlog, keep-alive) #2163
5. [tinker] Encode forwarded sample results to proto once and serve them as-is #2164
6. [tinker] Decode vLLM completion bodies straight into numpy with pysimdjson #2165
7. [tinker] Load harness for the API server's sampling path at 131k concurrency #2166

🤖 Generated with Claude Code

---

Note

Low Risk
Logging configuration only; no request handling, auth, or data path changes—access output format may look slightly plainer on stderr.

Overview
HTTP access logging for the Tinker API (via get_uvicorn_log_config) no longer goes through RichHandler. A dedicated access StreamHandler on stderr uses the same text formatter, while uvicorn and uvicorn.error still use Rich for startup, errors, and tracebacks.

This targets per-request access log volume: Rich’s table rendering was a major event-loop CPU cost under high QPS. Access lines should read the same format string but without Rich styling.

^{Reviewed by Cursor Bugbot for commit 254499a. Bugbot is set up for automated code reviews on this repo. Configure here.}

[gemini-code-assist]

Code Review

This pull request replaces the default RichHandler with a plain StreamHandler for Uvicorn's access logs to reduce CPU overhead under high request volumes. The reviewer suggested routing access logs to stdout instead of stderr for better log separation in production environments, and using direct class references for configuration consistency.

[gemini-code-assist]

There are two improvements we can make to the new access handler configuration:

1. Standard Log Separation (stdout vs stderr): In production and containerized environments, it is a standard best practice to route HTTP access logs to stdout and system/error logs to stderr. This allows log aggregators and monitoring tools to easily filter and separate normal traffic logs from errors. Uvicorn's default configuration also routes access logs to sys.stdout and error logs to sys.stderr.
2. Configuration Consistency: The "default" handler configuration uses the class reference directly via "()": RichHandler. Using "()": logging.StreamHandler for the "access" handler is more consistent and avoids string-based class resolution.

Suggested change

	"access": {
	"class": "logging.StreamHandler",
	"formatter": "default",
	"stream": "ext://sys.stderr",
	},
	"access": {
	"()": logging.StreamHandler,
	"formatter": "default",
	"stream": "ext://sys.stdout",
	},

[greptile-apps]

Confidence Score: 5/5

The PR appears safe to merge with no actionable defects identified.

The new handler is compatible with the existing standard formatter, preserves stderr output, and remains isolated by disabled propagation.

Important Files Changed

Filename	Overview
skyrl/utils/log.py	The dedicated access handler preserves the existing formatter, stderr destination, log level, and propagation behavior while removing Rich rendering from request logs.

_{Reviews (1): Last reviewed commit: "[tinker] Route uvicorn's access log to a..." | Re-trigger Greptile}