mirror of
https://github.com/fawney19/Aether.git
synced 2026-09-02 09:20:22 +08:00
cadc45c5b8
The stale-pending cleanup task previously hardcoded status_code=504 and a generic timeout message for every usage row it finalized. When a request had already been observed as failing — e.g. upstream Connection reset by peer, watchdog 504, or an authenticated 4xx — the cleanup overwrote that context with a misleading "服务器超时" outcome and 504 status, hiding the real cause from the dashboards and customer. Pull the most recent failed/cancelled candidate per stale request_id and, if present, finalize the usage row with the candidate's status_code (defaulting to 502 when none was recorded) and error_message. Requests that have no terminal candidate (truly stuck pending/streaming) keep the existing 504 + timeout-message behavior, since they really are timeouts from the cleanup's perspective. Applied to all three SQL backends with parameterized UPDATE statements. The Postgres failed-candidate lookup orders by COALESCE(finished_at, started_at, created_at) DESC, matching the MySQL and SQLite ORDER BY clauses so the three backends pick the same "most recent terminal candidate" under every NULL combination of timing columns. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>