503 error - continue?

[drag1c]

When running build_task in the MiroFish backend, the process fails with a 503 error from Zep Cloud:
[2026-04-13 00:51:14] ERROR [mirofish.build.build_task:497] Graph build failed: headers: {...}, status_code: 503, body: {'message': 'Service temporarily unavailable. Please retry.'} Traceback (most recent call last): File "C:\Users\drag1\MiroFish\backend\app\api\graph.py", line 440, in build_task episode_uuids = builder.add_text_batches(...) File "C:\Users\drag1\MiroFish\backend\app\services\graph_builder.py", line 325, in add_text_batches batch_result = self.client.graph.add_batch(...) File "C:\Users\drag1\MiroFish\backend\.venv\Lib\site-packages\zep_cloud\graph\client.py", line 249, in add_batch _response = self._raw_client.add_batch(...) File "C:\Users\drag1\MiroFish\backend\.venv\Lib\site-packages\zep_cloud\graph\raw_client.py", line 397, in add_batch raise core_api_error_ApiError(...) zep_cloud.core.api_error.ApiError: status_code: 503, body: {'message': 'Service temporarily unavailable. Please retry.'}
13845 credits spent for this calculation. Is there option for retry/continue?

[dosubot]

Hi @drag1c! I'm Dosu and I’m helping the MiroFish team.

Unfortunately, MiroFish does not currently support retry or resume for graph builds. The build_task and add_text_batches paths use a fail-fast approach — when a 503 (or similar) error occurs, the entire operation aborts with no checkpoint saved [1] [2]. This means the build must be restarted from scratch.

A few things worth noting:

• Retry utilities exist in the codebase (e.g., retry_with_backoff decorator, RetryableAPIClient) but they are not applied to the add_text_batches code path that failed here [3].
• 503 and rate-limit errors (429/500) are a recurring pain point, especially on Zep Cloud's free tier which limits to 5 requests/minute [4] [5].
• PR #291 proposes checkpoint/resume support for interrupted graph builds (by switching to a local Graphiti + Neo4j setup), but it remains unmerged.

Workarounds for now:

1. Retry the build manually — the 503 is a transient "service temporarily unavailable" from Zep Cloud, so a subsequent attempt may succeed.
2. Add delays between batches — there's already a 1-second delay between batch submissions [6], but if you're hitting rate limits, you could increase this in the source code.
3. Check your Zep Cloud tier — free-tier rate limits are a common cause of these failures. Upgrading or reducing concurrent polling may help.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}