--quiet hides the error message when a command fails

Ouverte
  • Quelque chose ne va pas ?
#2,876 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
3/5
Temps estimé
Une demi-journée
Accessibilité débutants
52/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
rust
Domaine
cli

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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

Langage dominant
Rust
Étoiles
129
Forks
153
Merge moyen
1 j 14 h
PR mergées (30 j)
11

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de stellar/stellar-cli

Toutes les issues de stellar/stellar-cli

Issues similaires

Plus d'issues Rust

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.