Struct CreateJobRequest 

pub struct CreateJobRequest {

    pub name: String,
    pub description: Option<String>,
    pub algorithm: String,
    pub robot_id: String,
    pub project_id: Option<String>,
    pub project_name: Option<String>,
    pub env_name: Option<String>,
    pub task_name: Option<String>,
    pub total_timesteps: Option<i64>,
    pub n_steps: Option<i64>,
    pub n_epochs: Option<i64>,
    pub learning_rate: Option<f64>,
    pub patience: Option<i64>,
    pub min_delta: Option<f64>,
    pub config_yaml: Option<String>,
    pub resume_run_id: Option<String>,
}

Request body for POST {control_plane_url}/api/model-deployments/jobs - field-for-field the same shape as mecha10-api/src/jobs/types.rs::CreateJobRequest (and, transitively, packages/dashboard’s types/ml-training.ts CreateJobRequest/buildCreateJobRequest, PR #278/LAB-1431). Deliberately duplicated rather than shared via a crate dependency - the CLI and API are different deployables and this struct is the wire contract, not shared code.

Fields

name: String

description: Option<String>

algorithm: String

robot_id: String

FK to the robots entity (LAB-2724) - required server-side since Job got a real robot_id column; omitting it fails job creation with a 422 “missing field robot_id”.

project_id: Option<String>

project_name: Option<String>

The project’s real name (mecha10.json’s name field), forwarded to train.yml’s project_name input so entrypoint.sh uses it for mecha10-launcher start --project-name instead of a hardcoded placeholder - mirrors mecha10 run remote’s MECHA10_PROJECT_NAME convention. Distinct from project_id above (an MLflow experiment-prefix concern, not a robot identity concern).

env_name: Option<String>

task_name: Option<String>

total_timesteps: Option<i64>

n_steps: Option<i64>

n_epochs: Option<i64>

learning_rate: Option<f64>

patience: Option<i64>

min_delta: Option<f64>

config_yaml: Option<String>

Raw content of the job’s own configs/rl/jobs/<name>.yml file, read off local disk right here at job-creation time (see to_create_job_request) and forwarded by mecha10-api into train.yml’s config_yaml_b64 input - the actual training config the trainer container runs with. This replaces relying on the trainer container re-pulling that file at runtime via mecha10-launcher, which raced the container’s own startup and silently no-op’d on failure (mecha10-rl’s rl-trainer/entrypoint.sh doc comment). LAB-2970: the job file itself is now the whole training config (no more separate configs/rl/local.yml), so this is simply the job file’s own bytes, unchanged in shape/semantics from before.

resume_run_id: Option<String>

MLflow run ID to resume from - forwarded to mecha10-api’s CreateJobRequest, which dispatches resume-run.yml instead of train.yml when this is non-empty (see mecha10-api/src/jobs/handlers.rs::resume_flow_inputs).

Trait Implementations

impl Clone for CreateJobRequest

fn clone(&self) -> Self

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for CreateJobRequest

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Serialize for CreateJobRequest

fn serialize<__S>(&self, __serializer: __S) -> Result<__S::Ok, __S::Error>

where __S: Serializer,

Serialize this value into the given Serde serializer.