Batches, retries, a batch that never works, and a stale check
The embedding service is a fake that fails on a schedule, and time is a counter, so the run is instant and identical in every language. Real clients also need jitter (random spread) in their waits.
Ingestion is a pipeline of stages. Embedding calls go out in batches, failures are retried with waits, one failed batch must not stop the rest, and changing the chunker or model means a planned backfill.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 6 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Write batches(items, size) returning a list of lists. Print the batches for [1, 2, 3, 4, 5, 6, 7] with size 3, one per line, joined by commas.
Write backoff_total(failures, base_ms) returning the total wait for a call that fails failures times before succeeding, with waits base_ms, 2 * base_ms, and so on. Print it for 3 failures with a base of 100.
Explain it without notes
Why batch embedding requests, and what limits the batch size?
Explain exponential backoff and what the retry loop in the example does.
What should a pipeline do when one batch fails permanently?
How do you handle a change of embedding model for a corpus that is already indexed?
Expected output
batch 1 (4 chunks): ok on attempt 1
batch 2 (4 chunks): ok on attempt 2
batch 3 (2 chunks): gave up after 3 attempts
stored 8 of 10, to retry next run: c8, c9
time spent waiting: 400 ms (simulated)
backfill: 8 of 8 stored chunks were made by an older chunker