[maxmad64bis]

⚠️ base-red inherited: #15306

Summary

Usage rows went missing when the database was busy, since a locked write was logged and dropped. A write that meets a lock is now retried once after a short delay, off the request path, and it's dropped with the same log line when the second try meets a lock too. Builds on @W25X80's diagnosis from #16176.

Related Issues

• Related to fix(resilience): job history SQLite errors can terminate the server #16176

Target Branch

• Base is the active release/v3.8.x branch (the highest open release/v*), not main
• New feature? From 3.8.55 on it is held with the v4-feature label for the v4 channel

Validation

• Change type: DB
• Focused tests and category gates from the golden path
• npm run lint
• Reconciled with the current active release base; focused checks rerun afterward
• Production-code changes include a new or updated automated test in this PR

Tests Added Or Updated

• tests/unit/usage/usageWriteRetry.test.ts — covers the lock check plus 5 write cases: lock then free writes one row, lock twice drops it with the log line and no third try, a non-lock error logs at once with no retry, a first-try success never writes twice, and the retry replays the first-try timestamp.

Coverage Notes

• src/lib/usage/usageWriteRetry.ts — covered by tests/unit/usage/usageWriteRetry.test.ts.
• src/lib/usage/usageHistory.ts — covered by tests/unit/usage/usageWriteRetry.test.ts and the existing usage suites.

Reviewer Notes

• Behavior: the first lock failure stays silent so a busy disk emits fewer log lines, the retry doesn't chain a third try, and a stop during the wait loses the row as before on a best-effort basis.
• Merge: either order with fix(call-logs, proxy-logs): retry a locked write once after a short delay #16390; each touches src/lib/usage/usageWriteRetry.ts and tests/unit/usage/usageWriteRetry.test.ts.
• Follow-up: the same one-shot retry for the request log and the proxy log batch waits for a daughter issue once this shape is accepted.