CodeBaobab
Data & Systems55 minutes

Idempotent Enrichment Client

Add retries and a concurrency limit to a client for a billed model API.

JavaScript

Task

This client sends records to a model API to be enriched. The API fails sometimes, bills for every call it processes, and limits how fast it may be called. Today the client sends one call per record, one at a time, and gives up on the whole batch at the first failure. Add retries that never double-bill and never flood the API. A scripted API and a virtual clock are supplied, so a whole batch runs with no network and no real waiting.

Requirements

  1. runBatch(scenario) is supplied. It runs your enrichBatch(records, deps, options) against a scripted API and returns {results, stats}. results has one entry per record, in input order: {id, status: "ok", value, attempts} or {id, status: "failed", reason, attempts}. attempts is the number of calls made for that record. reason is "timeout" or "http_" plus the status, from the last call. Do not change the records.
  2. Retry a call only when trying again can help: a rate limit (429), a server error (500 to 599) or a timeout. Never retry any other answer. Make at most maxAttempts calls for one record (default 4). One record that fails must not stop or fail the others.
  3. The API bills every call it processes, and the answer to a processed call can be lost on the way back. No record may be billed twice.
  4. Keep at most maxInFlight calls in flight at any moment, retries included (default 5), and use the slots: do not send the batch one call at a time.
  5. Wait before every retry, with deps.sleep only: baseDelayMs (default 100) after the first failed call for a record, twice that after the second, and so on. When the error has retryAfterMs, wait at least that long.
  6. records must be an array (TypeError containing records). maxInFlight and maxAttempts must be positive integers (RangeError containing the option name). An empty batch returns no results and makes no calls.
How you are graded
  • Decomposition 15%
  • Prompting the assistant 15%
  • Verification 20%
  • Judgment about AI output 15%
  • Correctness 25%
  • Communication 10%

Scores use evidence from your session. A short or incomplete session may not provide enough evidence for every skill. See a sample scorecard

Interview guidance

This client sends records to a model API to be enriched. The API fails sometimes and bills per call. I want retries that never double-bill and never flood the API. There is a scripted API and a virtual clock in the file, so you can run a whole batch in the checks. Use the AI assistant however you like. Before you prompt for code, tell me your retry policy: which failures you retry, which you do not, and why.

  • AI is allowed and expected: your own Claude, OpenAI or Gemini key, or the free in-browser model.
  • You are graded on how you drive and check the AI, not on how much you prompt.
  • Run the checks; read what fails.
  • A new requirement will arrive partway through.
  • Too little AI use is reported as “not enough to grade”, never as a fail.
You will answer 7 debrief questions at the end
  • What did you delegate to the AI, and why?
  • Name one AI suggestion you rejected or changed, and why.
  • Choose one block the AI helped write. Explain what each line does and which test verifies it.
  • What is still risky, and what would you test or ship next?
  • What is your retry policy, and which part of it did you decide before prompting?
  • How do you know no record is billed twice? What did you look at to check it?
  • Where does your code limit the calls in flight, and does a record hold its slot while it waits to retry? What does that choice trade?