--quiet hides the error message when a command fails

Abierto
  • ¿Algo no está bien?
#2,876 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
Medio día
Aptitud para principiantes
52/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
rust
Área
cli

Línea de trabajo

The final error line is printed via printer.errorln in cmd/soroban-cli/src/cli.rs (around line 106), and the --quiet flag is defined in cmd/soroban-cli/src/commands/global.rs. Start by reading how the printer suppresses output under quiet mode, then decide how a failing command's error reaches stderr while progress lines stay hidden. Done when stellar -q tx sign with a bad key prints the error and still exits 1, and successful quiet runs and --output json behavior are unchanged.

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

Descripción

What's wrong:
With -q / --quiet, a failing command exits 1 and prints nothing: no error on stderr and nothing on stdout. For example, with CLI 28.1.0:

$ stellar -q tx sign --sign-with-key nobody --network-passphrase "Test SDF Network ; September 2015" < tx.xdr
$ echo $?
1

Without -q the same command prints ❌ error: .... The flag's help says it means "Do not write logs to stderr including INFO" (v28.1.0 global.rs#L27-L29), but the final error line goes through the same quiet-aware printer as the progress lines (v28.1.0 cli.rs#L106, printer.errorln(format!("error: {e}"))). Before #1584 (September 2024, about contract init error handling) the error was always written with eprintln!; that PR moved it to the printer.

Impact:
-q is what scripts and agents use to drop the progress lines (for example LATCH passes --quiet on every call), so it's the mode where a readable failure matters most. Under -q the only signal is the exit code, so a script or a coding agent can't tell a missing identity from a network error or a contract failure, and logs show nothing to debug.

How we found it:
While checking how scripts and agents drive the CLI, as part of a review of HackMeridian 2026 hackathon repos (147 public repos) against CLI 28.1.0. Reproduced with the 28.1.0 release binary on 1 November 2026. Some repos wrap every CLI call in --quiet (for example LATCH scripts/testnet/bootstrap.mjs#L70-L72), so any failure there surfaces only as an exit code.

Outcome we're after:
When a command fails under -q, the reason is still available to the caller. How to get there is up to the implementer.

Compatibility: Successful runs under -q should stay as quiet as today, and exit codes shouldn't change.

How to check:

  • stellar -q tx sign --sign-with-key nobody ... < tx.xdr exits 1 and the reason is available.
  • A successful stellar -q contract deploy ... still prints only the contract ID.
  • Commands that already emit JSON errors with --output json behave as before.

Related: #2622 (structured output and errors), #2635 (JSON error output for commands with --output json, which still works under -q), #1840 and #2300 (-q also silences the detailed tx sign output), #1971 (closed; alias ls info lines on stdout ignore -q).

Lenguaje dominante
Rust
Estrellas
129
Forks
153
Merge medio
1 d 14 h
PR fusionados (30 d)
11

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 stellar/stellar-cli

Todos los issues de stellar/stellar-cli

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.