Run a failed evaluation again
Re-files a failed run’s own request and returns the NEW evaluation, in
queued. The original is left alone, with retried_by pointing at the
successor — the failure stays on the record, because error.code is the
only thing that can answer whether retrying was worth it.
This is the one submission in this API that is idempotent, and it is
idempotent on the run being retried rather than on your request. A burst
of presses picks exactly one winner; every other press is handed that same
winner. POST /v1/evaluations has no such guarantee — see its
description.
It costs the ordinary price, and that is not paying twice. A run that
failed was refunded when it settled: in full on failed, and on partial
exactly the detectors that did not land. The detectors that DID land were
cached at the same moment, so the retry pays for the missing legs and gets
the rest from cache. It consumes a detect rate-limit slot like any
submission.
Refused with 400 when there is nothing to retry, and the message says
which case it is: the run has not finished, it did not fail, it delivered
every detector it was asked for, it analyzed no stored clip (submit it
fresh instead), it has already been attempted too many times, or it was
already retried and that retry has since been deleted.
Authorizations
Use a key created in the Playground. Keys begin with gk_.
Path Parameters
Evaluation identifier.
Response
A new evaluation, queued.
"evaluation"galileo, gemini Unix timestamp in seconds.
x >= 0queued, processing, completed, partial, failed Why the run failed, on a failed one. NULL on a run that did not fail, and ABSENT on rows written before this field existed.
Not in required, and that is a correction rather than a preference: it was, and the older rows in the store do not carry the key at all. A client that enforced the contract at runtime — the Python one does, since its models validate — raised on any page deep enough to reach them, while the TypeScript client passed because its types are erased before a response is ever seen. So the contract was not merely wrong, it was wrong in a way that only one of the two clients could report.
Test for a VALUE, not for the key.
Per-detector state. Older evaluations may omit this field.
Stored video identifier when the evaluation used an uploaded video.
Which try this is. 1 for a run submitted directly; 2 or more for one produced by POST /v1/evaluations/{evaluation_id}/retry. There is a ceiling, so a clip that keeps failing under the same instructions stops being retryable rather than being retried forever.
x >= 1How long this run took. NULL when nothing was measured -- which is every run settled before it was recorded, and is not backfillable.
Null and never 0. A run whose latency nobody recorded and a run that took no time are different claims, and only one of them is true.
NOT in required, for the same reason error is not: during a rolling deploy some tasks are still the older build, and a response from one of those carries no such key. A client that enforces the contract at runtime -- the Python one does -- would raise on those responses, and it would raise only during a deploy, which is the worst time to be debugging a client. Test for a VALUE, not for the key.
Whatever you passed on create, echoed back. NULL when you passed nothing -- the key is always present, its value says whether there was any. Only found by submitting through the API. Every evaluation created in the console carries metadata, so a contract checked against console traffic alone looked correct here.