Skip to main content
This REST example prepares one retained evaluation fixture, then runs two deterministic cases and one deliberately slow case from that image. It records application item IDs, operation IDs, input image UUIDs, and result image UUIDs, then cancels only the slow operation owned by this batch.

Prerequisites

Complete Set up access. In a fresh project, run uv init --python 3.12 followed by uv add "httpx==0.28.1". Export NEBIUS_API_KEY, NEBIUS_PROJECT_ID, and IMAGE_UUID; the script supplies the public API URL by default. Use an Alpine 3.19 image UUID, or an equivalent image with /bin/sh, mkdir, cat, chmod, test, printf, sleep, and /etc/os-release. The fixture relies on these commands and the OS release file.

Read the outcomes

The three cases start from the same prepared image. The pass case checks a file that exists. test-fail checks a missing file. slow-cancel waits in a loop until the client cancels it after collecting the other results. A 120-second execution timeout bounds the guest process if cancellation cannot be confirmed. The final records should report passed, test-failure, and cancelled, each with its own operation ID. A command failure stays separate from a platform failure so it does not count as an infrastructure error in your evaluation results. This example caps work by submitting exactly three cases. The HTTP connection limit controls client connections, not the number of remote operations. For a larger dataset, hold a semaphore or worker slot from submission until each operation reaches a terminal state; see Run concurrent workloads.

Run the complete example

Save as bounded_eval.py:
Run uv run python bounded_eval.py. The program prints accepted IDs as it submits work, followed by a labelled summary with these outcomes (UUIDs vary):
The client collects the first two outcomes before requesting cancellation of slow-cancel. The slow fixture keeps waiting during that step, with its execution timeout as a fallback bound. Each disposable result has no result image. The retained fixture image UUID and fixture markers in stdout or stderr make each outcome inspectable. The example bounds evaluation work to three accepted operations and all waits with deadlines. The public Beta maximum is 50 simultaneous operations; it is a ceiling, not a target. An accepted operation has outcome=None until a terminal result is observed. If cleanup cannot confirm that result, it reports cleanup-uncertain. Transport failure after acceptance is uncertain, so query a known ID before resubmitting. Cleanup sends DELETE only for IDs inserted into owned_operation_ids and observes terminal state; it never uses project-wide cancellation. The retained fixture follows the image retention policy. Recover cancelled work from a known-good image; contact support if cancellation billing or retention affects your workload. See Run concurrent workloads.