fix(kb): retry-with-backoff on embed_content, fixing intra-file 429 bursts - #170
Open
asachs01 wants to merge 3 commits into
Open
fix(kb): retry-with-backoff on embed_content, fixing intra-file 429 bursts#170asachs01 wants to merge 3 commits into
asachs01 wants to merge 3 commits into
Conversation
…content embed_content() had zero retry logic while generate_content already retries transient 429/500/503 errors via _retry_generate_content. A large text file (e.g. an agent's MEMORY.md) embeds every chunk back-to-back with no pacing, so once the file's own chunk volume trips the shared embedding quota, every remaining chunk in that run also 429s with nothing pausing for recovery — the ingest dies partway through on every attempt, independent of any cross-agent contention (confirmed via isolated reproduction and adoption's MEMORY.md failing 5 consecutive staggered-schedule ingests). Adds _retry_embed_content mirroring the existing _retry_generate_content pattern exactly, wires embed_content() through it. Extends the fault_injection test harness to script embed_content independently of generate_content, with 4 new regression tests.
…ackoff /simplify review of the prior commit found _retry_embed_content was a near-verbatim copy of _retry_generate_content (same loop, same transient-code classification, same backoff shape — only the wrapped call differed). Collapse both into a single _retry_with_backoff(fn, label=...) taking a zero-arg callable, so a third retry-needing call site only needs a lambda, not a third copy of the loop. Also merges test_retry_embed.py into test_retry.py: since there is now one implementation, testing it via two near-duplicate suites (one per call shape) re-introduced the same duplication at the test layer. test_retry.py now runs each scenario against both a generate_content-shaped and an embed_content- shaped call through a shared table, plus a cross-shape independence check. Reviewed and deliberately NOT addressed here (would require changes well outside this diff): proactive inter-chunk pacing in the ingest loops themselves (retry-after-failure treats the symptom; the tight per-chunk loop is what generates the burst) — flagged by /simplify's altitude pass as the deeper fix, tracked for follow-up rather than expanding this diff's scope. Also not changed: the backoffs=(5,15,45) default is borrowed from generate_content's tuning, not independently measured for embedding's burst window — real-world validation is pending against a live large-file ingest.
|
Warning Review limit reachedNext included review available in 1 minute. View limit detailsLimit details: You’ve used all 10 included reviews currently available. Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. Review configuration: ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (3)
Comment |
Caught by analyst's independent review of #170 (ran the test suite in an isolated worktree rather than trusting the PR description): mmrag.py:860's comment and fault_injection.py's module docstring still named the pre- consolidation function. Cosmetic only, no behavior change.
2 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
embed_content()had zero retry logic whilegenerate_content()already retried transient 429/500/503 errors — a large file (e.g. an agent's MEMORY.md, ~238 chunks) embeds every chunk back-to-back with no pacing, so once the file's own chunk volume trips the shared embedding quota, every remaining chunk in that run also 429s with nothing pausing for recovery. Confirmed via isolated zero-contention reproduction and adoption's MEMORY.md failing 5 consecutive already-staggered ingest cycles (task_1788420454462_38838015)._retry_with_backoff(fn, label=...)shared by bothgenerate_contentandembed_content, rather than shipping a second near-duplicate retry loop — caught by a/simplifyreview pass (reuse/simplification/efficiency/altitude, 4 parallel agents) after the first commit.test_retry.py) that exercises both call shapes through a shared table, since there's now one implementation to test.What's deliberately NOT addressed here
backoffs=(5,15,45)is inherited fromgenerate_content's tuning, not independently measured for embedding's burst window. Real-world validation pending against adoption's next live MEMORY.md ingest.Test plan
python -m _test_clients.test_retry— 7 scenarios, 19 assertions, all passNeed help on this PR? Tag
@codesmith-botwith what you need. Autofix is disabled.