Summary
reqwest::Client is currently being rebuilt for virtually every request instead of being reused.
This affects qf_api, Discord/webhooks, and profile fetches.
Steps to Reproduce
- Start the app
- Perform an action that triggers a qf-api request, e.g., login, market, alerts, or cache
- Trigger another request
- For each individual request, a new client—including a new connection pool—is created in
qf_api::Client::call_api.
The same thing happens with every Discord/webhook notification and with profile fetches.
Expected Behavior
The client should be created once and then reused.
Headers such as auth-token, wfm-token, etc., must still be set for each request because they can change.
Actual Behavior
Because a new client is created for each request, keep-alive connections—or rather, the connection pool—are immediately lost.
This results in unnecessary TCP/TLS handshakes, increased latency, and more network/CPU overhead. With QF-API requests, this quickly adds up.
Additional Information
This is not a direct user-facing bug, but rather a performance/resource issue.
Summary
reqwest::Client is currently being rebuilt for virtually every request instead of being reused.
This affects qf_api, Discord/webhooks, and profile fetches.
Steps to Reproduce
qf_api::Client::call_api.The same thing happens with every Discord/webhook notification and with profile fetches.
Expected Behavior
The client should be created once and then reused.
Headers such as auth-token, wfm-token, etc., must still be set for each request because they can change.
Actual Behavior
Because a new client is created for each request, keep-alive connections—or rather, the connection pool—are immediately lost.
This results in unnecessary TCP/TLS handshakes, increased latency, and more network/CPU overhead. With QF-API requests, this quickly adds up.
Additional Information
This is not a direct user-facing bug, but rather a performance/resource issue.