Fix is_path inputs not transferred when using mlcrr

[Copilot]

When a script declares an input with is_path: true in input_description, the resolved absolute local path was forwarded verbatim into the rebuilt remote command — the remote host never received the file, and the path it received was meaningless.

Changes

• automation/script/remote_run.py: After the env_keys_to_copy loop, added a loop over input_description entries with is_path: true. For each matching key present in run_input that resolves to an existing local path:

  • Appends the local path to files_to_copy (rsync/scp'd to remote)
  • Replaces run_input[key] with <remote_copy_directory>/<basename> before regenerate_script_cmd rebuilds the command

  This mirrors the existing env_keys_to_copy mechanism exactly.

• tests/test_slurm_run.py: Added TestRemoteRunIsPath with 4 unit tests covering: file queued for transfer, path replaced in rebuilt command, non-existent path is a no-op, and is_path: false is a no-op.

✅ PR Checklist

✅ Testing & CI

• Have tested the changes in my local environment, else have properly conveyed in the PR description
• The change includes a GitHub Action to test the script(if it is possible to be added).
• No existing GitHub Actions are failing because of this change.

📚 Documentation

• README or help docs are updated for new features or changes.
• CLI help messages are meaningful and complete.

📁 File Hygiene & Output Handling

• No unintended files (e.g., logs, cache, temp files, pycache, output folders) are committed.

🛡️ Safety & Security

• No secrets or credentials are committed.
• Paths, shell commands, and environment handling are safe and portable.

🙌 Contribution Hygiene

• PR title and description are concise and clearly state the purpose of the change.
• All reviewer feedback has been addressed.

• Fixes is_path not working with mlcrr #315

[arjunsuresh]

@copilot this seems wrong. We do have explicit env_keys_to_copy as remote meta in the script. But this is not getting used by mlcrr

[Copilot]

@copilot this seems wrong. We do have explicit env_keys_to_copy as remote meta in the script. But this is not getting used by mlcrr

Good catch. The root issue is that env_keys_to_copy only checked self_module.env, but when mlcrr is invoked directly the engine skips the full run() pipeline, so env is never populated from input_mapping.

The fix (commit above) adds a fallback: when env[key] is absent/missing, the env_keys_to_copy loop now reverse-maps the env key back to its input key via input_mapping and checks run_input[input_key] instead. This covers the mlcrr path where env hasn't been pre-populated.

The is_path handling I added earlier is kept as a complementary mechanism for inputs that have is_path: true in input_description but no corresponding env_keys_to_copy entry — and it now deduplicates with env_keys_to_copy so the same file isn't transferred twice.

[arjunsuresh]

@copilot when mlcrr or any mlc command is called the first part is the meta update and input_mapping happens here. So, how can we have a case where an input variable is not mapped to its env variable? This was all working fine until 2 weeks back.

[Copilot]

@copilot when mlcrr or any mlc command is called the first part is the meta update and input_mapping happens here. So, how can we have a case where an input variable is not mapped to its env variable?...

You're right that input_mapping is applied during the normal run() pipeline, but mlcrr dispatches directly to automation_instance.remote_run(run_args) — run() is never called, so update_env_from_input_mapping never runs and self_module.env stays empty when env_keys_to_copy checks it.

Replaced the reverse-map fallback with a direct call to update_env_from_input_mapping(env, run_input, input_mapping, input_description) at the start of the env_keys_to_copy section (local import to avoid circular imports). This matches what run() does and restores the expected behavior cleanly.

[arjunsuresh]

@copilot then how was the copy working before two weeks? In mlcrr aren't we updating the meta from the script meta like we do for mlcd and mlca?

[Copilot]

@copilot then how was the copy working before two weeks? In mlcrr aren't we updating the meta from the script meta like we do for mlcd and mlca?

Looking at the history: remote_run.py has always only checked env[key] for env_keys_to_copy, and env in the mlcrr path has always been empty because run() is never called. So env_keys_to_copy was never actually working for mlcrr — the current issue title says "is not working" rather than "stopped working", which aligns with this.

docker.py is different: it explicitly calls self_module.update_state_from_meta() early in docker_run() (line 93 of docker.py), which applies default_env/env from meta to self_module.env. However even docker.py applies input_mapping separately via the docker_input_mapping block, not through update_state_from_meta.

The current fix — calling update_env_from_input_mapping(env, run_input, input_mapping, input_description) in remote_run.py before the env_keys_to_copy loop — mirrors what run() does and is the correct parallel to how docker handles its own docker_input_mapping. This makes both env_keys_to_copy and is_path work correctly for mlcrr.

[github-actions]

MLCommons CLA bot All contributors have signed the MLCommons CLA ✍️ ✅