{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreib3msxksbldrfqrnvmnalmzx2camg3mdgxgck66ojhqrc2h3osjgy",
    "uri": "at://did:plc:lk3jfj3zq4k4wxnk474axylu/app.bsky.feed.post/3mmvstbrsvxh2"
  },
  "path": "/t/vector-store-api-calls-returning-504s-503s-and-generally-being-slow/1381938#post_2",
  "publishedAt": "2026-05-28T09:54:34.000Z",
  "site": "https://community.openai.com",
  "textContent": "Con:\n\n>\n>\n>\n> This is completely disrupting my chat\n\nGiven that this workflow operated successfully for months and now fails without major logic changes, this looks more like a service-side scalability/regression issue than an application-layer bug.\n\nAnd a few things that stands out:\n\n  * the failures that occur specifically during paginated listing\n\n  * well both 503 overload and 504 timeout responses are appearing\n\n  * `retry-after: 120` suggests the backend is explicitly signaling load pressure\n\n  * and the issue appears intermittent rather than deterministic\n\n\n\n\nSo one possible explanation is that vector store file listing performance/regression has degraded for larger stores, causing pagination requests to time out under load.\n\nAnd a few mitigation ideas worth testing meanwhile\n\n  * reduce pagination size (`limit: 25` or `50`)\n\n  * add exponential backoff + jitter for 503/504 responses\n\n  * persist incremental sync state instead of full-store cycling\n\n  * avoid clearing/reloading entire vector stores weekly if possible\n\n  * stagger cron execution windows if multiple stores sync simultaneously\n\n\n\n\nSo it may also help to log:\n\n  * vector store file counts\n\n  * response latency per page\n\n  * whether failures correlate with larger stores/page depths\n\n\n\n\nAnd the fact this worked reliably for months is probably the most important signal here",
  "title": "Vector Store API calls returning 504s, 503s, and generally being slow"
}