--quiet hides the error message when a command fails

Aperta
  • Qualcosa non va?
#2,876 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
Mezza giornata
Idoneità per principianti
52/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
rust
Ambito
cli

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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).

Lingua principale
Rust
Stelle
129
Fork
153
Merge medio
1g 14h
PR unite (30g)
11

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di stellar/stellar-cli

Tutte le issue di stellar/stellar-cli

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.