Skip to content
Code Recycle

Component · for humans & their agents

Batch Tool Result Retry Split

verified · first-partyactively maintained$0 during beta (was $49)

A retry loop that reads the wrong field from a batch result re-sends work that already succeeded, or drops a failure forever. The JSON looks fine either way.

by ringbuffer · Code Recycle admin

Get it free — beta

Every claim on this page is refundable if it is untrue — refund policy.

Verified: 86 tests

Splits an agent's batch tool result into what must be retried and what must not, and refuses when the result cannot support that decision. Pure function over the result you already have.

Splits an agent's batch tool result into what must be retried and what must not, and refuses when the result cannot support that decision. Pure function over the result you already have.

THE SILENT FAILURE. An agent's tool call operates over a batch -- send 5 emails, write 10 rows, publish 20 notifications -- and gets back a per-item result where some succeeded and some failed. The retry has to re-send exactly the failures. Every way of getting this wrong is silent. Retry the whole batch and the successful items happen TWICE: five emails become ten, and nothing in the log looks abnormal. Index the results against the wrong array and the retry set is misaligned -- you re-send item 3 for item 4's failure. Read a truthy `status` field that means 'the call completed' rather than 'the item succeeded' and every failure is dropped on the floor, permanently, with a clean success log above it.

PARTIAL SUCCESS IS THE DEFAULT CASE, NOT THE EDGE CASE. Batch APIs return it constantly and the agent frameworks around them mostly model a call as succeeded-or-failed. This package treats a batch result as a set of independent outcomes and produces a retry set with the reason each item is in it.

IT REFUSES A BATCH IT CANNOT ALIGN. If the result cannot be put in correspondence with the request -- counts differ, ids are missing, an item carries no determinate outcome -- it returns a refusal naming the problem rather than a retry set that looks actionable and is misaligned. A confidently wrong retry set is the expensive failure here.

WHAT VERIFICATION CHANGED. A rival implementation built from the README failed one test, and the test was wrong: it pinned the ARRAY ORDER of the reasons attached to an item, which is an accident of implementation rather than a contract. It now asserts presence and determinism, so the suite survives a rewrite of the code underneath it.

VERIFIED: 86 tests, measured by running the suite, every mutation observed FAILING before restore.

DELIVERY: signed download of a hash-verified tarball, immediately on purchase. Permissive licence: unlimited products, unlimited clients, unlimited seats, no attribution, perpetual and irrevocable. One restriction, do not republish the source as source.

Interface

What you call, and what comes back. Types and signatures only — the implementation ships with the source.

  export function classifyItem(item: BatchItemResult): ItemVerdict;
  export function splitBatchForRetry(input: unknown): BatchRetrySplitResult;
  export function validateBatch(input: unknown): ValidationOk | ValidationFail;
  export type BatchItemStatus = "success" | "failure" | "unknown";
  export type ItemRetryDisposition = "done" | "retry";

01Capabilities

Does

  • + Idempotent fulfilment
  • + Retry and backoff policy
  • + Agent tool-call orchestration

Doesn’t

  • No exclusions declared

02Requirements & stack

Depends on

No declared dependencies

Credentials needed

None declared

Stack

typescript

03Community

No endorsements yet

No verified confirmations yet — be the first.

Confirmations come from verified purchasers, installers, vetted reviewers, or an installation outcome your org reported through the agent tools. They grade quality — security is verified separately, and community votes can never override the security gate.

Open an issue

Sign in to confirm — weight comes from verified usage, not vote count.

0 open · 0 answered · 0 fixed · 1 said it worked

04Trust Passport

Full passport →
–/100

0/0 automated components pass. An automated score is never a security guarantee.

✓ Verified · first-partyreviewed Sep 20, 2026 · re-verification due Dec 19, 2026
  • publisher identity Publisher status verified; 1 verification(s) on file
  • malicious pattern scan No known malicious-behavior patterns across 12 source file(s) plus listing text
  • capability contract All 0 observed capability reference(s) match the declared manifest
  • agent safety scan No injection patterns in agent-readable content
  • provenance No release signature or provenance attestation
  • behavioral sandbox Not performed in this environment — requires the production isolated runner (docs/sandbox-requirements.md). No untrusted code is ever executed on the application host.

Every listing must pass this review before it can be sold, and it is re-run on every release. Verification describes what we checked — it is not a guarantee that the software is safe.

VersionChannelReleasedNotes
1.0.0stableAug 6, 2026First public release.