Deployed Bodylog commit 0bb921c so OpenAI insufficient_quota responses are treated as non-retryable provider failures instead of transient rate limits.
Meal backfill recovery exposed a second issue: OpenAI returns HTTP 429 for both transient rate limiting and hard quota exhaustion. Bodylog treated every 429 as retryable, so a queue of meal enrichment jobs could sit in processing for several minutes each even though insufficient_quota cannot succeed through retry delay.
The June 7, 2026 pizza meal (meal_log.id = 821) was one affected record.
code=insufficient_quota or type=insufficient_quota from retryable rate-limit handling.openai_insufficient_quota_is_not_retryable_rate_limit.cargo fmt passed.cargo test openai_insufficient_quota_is_not_retryable_rate_limit passed.cargo test passed: 132 tests.git diff --check passed.autocoder build + deploy / build_and_deploy (push) succeeded for 0bb921c in 3m7s.bodylog/bodylog rolled out successfully on image gitea.app.lan/bodylog/bodylog.dev:sha-0bb921cac62f.code=insufficient_quota instead of retrying through backoff windows.meal_log.id = 821 moved to failed with the OpenAI quota error and there were zero processing or pending meals.Meal enrichment still requires OpenAI quota/billing availability. Once quota is restored, failed meals can be queued again by the normal meal backfill path.
Revert commit 0bb921c and push main to redeploy the previous retry behavior.