Skip to content

Vanguard: Keep batchId and accept replayed batches - #4

Merged
zpl-zak merged 4 commits into
mainfrom
vanguard/batch-retries
Oct 30, 2026
Merged

zpl-zak merged 4 commits into
mainfrom
vanguard/batch-retries

Conversation

@zpl-zak

@zpl-zak zpl-zak commented Oct 30, 2026 •

Copy link
Copy Markdown
Contributor

Summary

POST /v2/batches can be retried safely. The client sends a batchId (a ULID it chooses), and a second submission creates only the jobs not yet in the batch. The API then answers 200 with status replayed (nothing missing) or partial (missing jobs created now). The CLI broke this in two ways:

  • api.BatchCreation had no batchId, so batch submit silently dropped it from the request. Every retry became a new batch.
  • Only 201 counted as success, so a 200 replayed answer was reported as a failure with exit code 7.

Changes:

  • Spec: the batch schemas and the /batches responses are synced from nexrender/nexrender-api#188, and api.gen.go is regenerated. BatchCreation.BatchId now exists, and the replayed status, JSON200, JSON409 and JSON503 are typed.
  • batch submit:
    • 200 is a success. The summary says whether nothing new was created or which missing jobs were.
    • A 503 on a request that has a batchId gets the hint to run the same command again.
    • Each job's batchItemId already survives through JobCreation's additional properties; the new test pins that.
  • README: a sentence on how to make a batch safe to resubmit.
Response Before After
201 created/partial success success
200 replayed/partial (retry) error, exit 7 success
503 BATCH_RETRYABLE error error, with "run it again with the same batchId" hint

This repository only has main, so the PR targets it. Matching retries by batchItemId on the server needs nexrender/nexrender-api#187 and nexrender/nexrender-database#55.

Found by Vanguard, the new end-to-end suite.

Testing

  • New TestBatchSubmitKeepsBatchIDAndAcceptsReplay: the request carries batchId and batchItemId, and a 200 replayed response exits 0 with the replay summary. It fails without this change.
  • go generate ./internal/api, gofmt -l (clean), go vet ./..., go test ./..., go build ./cmd/nexrender.

zpl-zak and others added 4 commits October 30, 2026 07:52
The API lets a client retry POST /batches safely by sending a batchId:
a retry creates only the missing jobs and answers 200 with status
'replayed' or 'partial'. The vendored spec did not describe batchId or
the 200 response, so the CLI dropped batchId from the request and
reported a replay as an error.

The batch schemas and responses are synced from nexrender-api and the
client regenerated. `batch submit` keeps batchId (and each job's
batchItemId), treats 200 as success with a summary that says what the
retry did, and on 503 with a batchId tells the user to run the same
command again. The README explains how to make a batch retry-safe.

Found by Vanguard.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Synced from nexrender-api: retries are recognised for 30 days, while the
batch's jobs are kept.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A retry can answer 200 partial while still listing jobs that could not
be created; the summary now says so instead of claiming the missing jobs
were created. The README and the vendored spec say to send a retry only
after the previous attempt has finished, since overlapping requests with
the same batchId can both create jobs, and that batchItemIds must be
unique.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Synced from nexrender-api.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@zpl-zak
zpl-zak merged commit 7fa3362 into main Oct 30, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant