serve summary prints a stop command that fails without --yes

Cerrado Apto para principiantes
  • ¿Algo no está bien?
#417 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@jussielo-amd ya está trabajando en esto.

Desde el 8/10/2026.

  • #601 de @jussielo-amd — cerrado sin fusionar
  • #604 de @jussielo-amd — abierto

Evaluación

Dificultad
1/5
Tiempo estimado
Menos de una hora
Aptitud para principiantes
92/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
rust
Área
cli

Línea de trabajo

Empieza en apps/rocm/src/serve_summary.rs, en render_summary, y compara después la fila de detención con run_approved_service_action en apps/rocm/src/main.rs. Comprueba el test existente service_actions_require_yes_and_render_sandbox_result para obtener la forma canónica del comando. La tarea está terminada cuando el resumen del despliegue muestra un comando de detención que incluye --yes y coincide con la invocación verificada en el repositorio.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

bug

Current behavior

After rocm serve <model> succeeds, the deployment summary prints a stop row that is presented as a ready-to-run command:

service   vllm-qwen-1720000000
stop      rocm services stop vllm-qwen-1720000000
logs      rocm logs --service vllm-qwen-1720000000

Running that exact command fails. rocm services stop refuses to act unless --yes is passed, so the first thing a user does with the hint — copy it and paste it — exits non-zero with a requires --yes error.

The hint is built in apps/rocm/src/serve_summary.rs:134-139, where render_summary emits the service, stop, and logs rows. The logs row is complete, but the stop row omits --yes:

("service", summary.service_id.clone()),
("stop", format!("rocm services stop {}", summary.service_id)),
(
    "logs",
    format!("rocm logs --service {}", summary.service_id),
),

The gate it collides with is in apps/rocm/src/main.rs:6889-6902. run_approved_service_action bails whenever yes is false:

fn run_approved_service_action(
    paths: &AppPaths,
    tool: &str,
    service_id: &str,
    yes: bool,
) -> Result<()> {
    validate_service_id(service_id)?;
    if !yes {
        bail!(
            "{} local server `{service_id}` requires --yes.\n\nTry: rocm services {} {service_id} --yes",
            service_action_verb(tool),
            service_action_command(tool)
        );
    }

So the summary and the command implementation disagree about what the canonical stop invocation is. The error text is helpful — it tells you to add --yes — but the user only sees it after the printed command has already failed.

Expected behavior

The command printed in the deployment summary should be copy-pasteable and succeed as printed. The stop row should read:

stop      rocm services stop <service-id> --yes

A hint that cannot be run verbatim is worse than no hint, because it teaches the user a command form the CLI then rejects.

Steps to reproduce

  1. On an interactive terminal, run rocm serve qwen and wait for it to come up.
  2. From the deployment summary, copy the stop line exactly as printed.
  3. Run it verbatim.
  4. Observe the requires --yes error and a non-zero exit status. The service is still running.

Possible solution

Two options, and they point in opposite directions, so this is really a question about which form is canonical:

  • (a) Append --yes to the stop row in render_summary, so the printed hint matches what the command actually accepts.
  • (b) Leave the hint as the canonical short form and have rocm services stop prompt interactively when it is attached to a TTY, instead of bailing outright.

Option (a) is the smaller change and keeps the existing non-interactive safety gate intact — nothing about the approval semantics changes, only the string that gets printed. Option (b) is a larger behavioral change to the command itself and would need care around the non-interactive path.

Worth noting that the same question applies to rocm services restart, which shares run_approved_service_action and therefore the same --yes requirement. Whichever way this is resolved, both subcommands should end up consistent.

Your environment

  • rocm-cli channel: n/a
  • rocm-cli version (rocm --version): n/a
  • Platform: n/a
  • OS / Distro: n/a
  • GPU/APU: n/a

This was found by reading the source of main at commit 8557e680 (2026-09-17), not by executing a build, so the environment fields above are genuinely not applicable rather than omitted. The line numbers cited are as they appear at that commit.

Relevant log output

The bail! that rejects the printed command, apps/rocm/src/main.rs:6897-6901:

bail!(
    "{} local server `{service_id}` requires --yes.\n\nTry: rocm services {} {service_id} --yes",
    service_action_verb(tool),
    service_action_command(tool)
);

The stop row that produces the command, apps/rocm/src/serve_summary.rs:135:

("stop", format!("rocm services stop {}", summary.service_id)),

Additional context

Surfaced while fact-checking a hands-on blog post against main — the post reproduced the stop command straight out of the deployment summary, which is exactly the failure path a reader would hit.

Worth adding that the canonical form is already specified in-tree. The test service_actions_require_yes_and_render_sandbox_result at apps/rocm/src/main.rs:25601-25608 asserts that the stop error contains both "requires --yes" and "rocm services stop svc-qwen --yes":

let error = run_approved_service_action(&paths, "stop_server", "svc-qwen", false)
    .unwrap_err()
    .to_string();
assert!(error.contains("requires --yes"));
assert!(error.contains("rocm services stop svc-qwen --yes"));

So the repository already treats rocm services stop <id> --yes as the correct invocation and has a test pinning it. The summary row at serve_summary.rs:135 is simply out of sync with that, which makes option (a) the obviously correct fix — it aligns the printed hint with a form the tree already asserts.

Lenguaje dominante
Rust
Estrellas
49
Forks
14
Merge medio
2 d 20 h
PR fusionados (30 d)
171

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de ROCm/rocm-cli

Todos los issues de ROCm/rocm-cli

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.