[ar-api] Return Action Recognition training IDs from CLI (VID-34) - #537
Merged
Merged
Conversation
joaomarcoscrs
approved these changes
Oct 1, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
CLI users starting Action Recognition training received no run ID. That made a new run hard to identify when a version could hold several trainings.
The command now uses the existing v2 training endpoint for the supported Action Recognition model, even without a recipe. It prepares the required video export and prints the run ID in JSON and text.
Explicit recipes keep their validation and
--epochsbehavior. Other recipe-free models keep their existing route. Command help notes the distinction briefly.Validation
python -m unittest tests.cli.test_train_handler.TestActionRecognitionTrainCLI tests.cli.test_train_handler.TestTrainStartV2 tests.test_version tests.test_rfapi tests.util.test_versions: 90 passed on0e91b4a.video-cocoexport, a v2 request withouttrainRecipeor recipe GET, returned ID in text/JSON, legacy non-AR and Cosmos VLM routes, explicit recipe with epochs, and malformed recipe rejection.make check_code_quality(Ruff format/check and mypy), test-file Ruff checks, andgit diff --checkpassed.api.roboflow.com; DNS is restricted in this session. It did not reach that endpoint.Staging E2E (live, October 1, 2026)
The private staging version was generated with
video-cocoalready exported. The API key was supplied only through the environment.Input:
$ roboflow --json --workspace model-evaluation-workspace train start -p punch-hook-actions -v 2 --type cosmos3-edge --epochs 1Output (exact sanitized CLI JSON, exit 0):
{"status":"running","project":"punch-hook-actions","version":2,"trainingId":"00395fbde08e0757e83d","jobId":"punch-hook-actions-2-f7hzx"}Input (read back the exact new run):
$ roboflow --json --workspace model-evaluation-workspace train list punch-hook-actions/2Output (selected record):
{"id":"00395fbde08e0757e83d","modelType":"cosmos3-edge","status":"running","modelIds":[]}One recipe-free CLI start created this run. The status read confirms it persisted; terminal training outcome is pending.
Platform contract and runtime limit
At platform
roboflow/roboflowmaster53dcfc1804da41f629e291ec5d6e8e4ef8573918, the existing v1POST /trainreturns 204 without a run ID; v2POST /v2/trainingsreturns 200 withtrainingId,status, andjobId. This SDK PR needs no new platform route or deployment target. Fixtures cover the request shape and guards. One live staging CLI creation succeeded and returned a persisted training ID; the run is still in progress, so job completion and model usability remain unverified. This staging result does not establish production deployment or package publication. Package publication is separate from this PR.