[USG-001] 记录使用量失败: {e}：cc-switch

Quick fix

Move the full usage calculation and SQLite write to spawn_blocking, and use a bounded retry queue for failed writes.

Symptom

Error outputCopy

[USG-001] 记录使用量失败: {e}

English translation

[USG-001] Failed to record usage: {e}

Cause

The usage-recording path synchronously acquires Mutex<Connection> and performs disk I/O in the Tokio async context. Lock contention or a slow disk can block runtime worker threads and stall streaming responses. The original caller only logs a warning and does not retry failed writes, leaving gaps in usage statistics.

The issue discusses two implementation approaches. One moves price lookup, calculation, and writing together into spawn_blocking, and covers paths such as log_forward_error. The other also adds a bounded retry queue. With the latter, records may still be lost after five failed retries, when the queue reaches 10,000 entries, or when the process exits. Whether a persistent queue is needed remains an open design decision.

Fix

1. 1

   Move the complete database access chain—price-source reads, usage calculation, and SQLite writes—into spawn_blocking to avoid holding Mutex<Connection> on Tokio worker threads.

2. 2

   Add a bounded retry queue for failed writes. The implementation in the issue retries up to 5 times, with linear backoff from 250ms to 1s, and logs an error including the request ID when records are finally discarded or the queue is full.

3. 3

   Also check log_forward_error and its async handler call chain to ensure hot paths using the same database lock do not block the runtime inline.

Affected Versions

Toolcc-switch

VersionUnknown

PlatformsUnknown

Source Issues

This page is distilled from 1 real issues

• #7818Usage-stats write blocks the tokio runtime and drops records on failure

FAQ

Can usage records be discarded?

The bounded queue discussed discards records after all 5 retries fail, when the queue reaches 10,000 entries, or when the process exits. A separate persistent storage solution is required if records must never be lost.

Is WAL required?

The issue analysis states that the application has only one connection serialized by Mutex<Connection>, so WAL provides no multi-connection read/write concurrency benefit and adds -wal and -shm sidecar files and backup risks.

Related problems

Codex session import ignores cache_write_input_tokensUpgrade cc-switch or wait for an official fix: Codex session log import misses cache_write_input_tokens, so cache writes are counted as ordinary input and…1 issues merged[CODEX-SYNC] deferred 4 CodexUpgrade cc-switch to v3.20.3 to fix Windows session files permanently deferred when mtime does not change.1 issues mergedCost always 0: GPT-6 Sol usage statistics in CodexEnable “Model Price Sync” in Settings to synchronize pricing data for gpt-6-sol.1 issues merged