CodeCartography became extremely slow and the Issues view returned HTTP 504. PostgreSQL was continuously using approximately one CPU core.
The Issues API performed per-issue activity and lifecycle reads. In parallel, the shared account/task-board request selected large stored worker traces (about 31 MB for the latest 50 ended jobs) and used an OR-based lifecycle lookup that did not use the existing task-id indexes. The task-board query ran for roughly 10 seconds and immediately repeated, blocking other API work on the shared database client.
5c9b2f5fa1d7e57602fb573df5b1f80b8e0fc6f5.gitea.app.lan/autocoder/autocoder-engine:dev-5c9b2f5fa1d7 to development and production. Previous production image: gitea.app.lan/autocoder/autocoder-engine:dev-fdb195336094.https://codecartography.dev/ returned HTTP 200 in 14 ms.https://codecartography.dev/api/auth/session returned HTTP 200 in 15 ms.5c9b2f5fa1d7e57602fb573df5b1f80b8e0fc6f5.The production ConfigMap retained AUTOCODER_BACKGROUND_AUTOMATION_ENABLED=false, AUTOCODER_IMPLEMENTATION_WORKERS_ENABLED=false, and AUTOCODER_REQUIREMENTS_AUTOMATION_ENABLED=false. No work admission was enabled. Roll back the backend deployment to immutable image dev-fdb195336094 if required; the additive indexes are safe to retain.