microcks / microcks/microcks-cli
CLI crashes with panic if Microcks API returns unexpected responses
Personne n'a encore pris cette issue.
- Langage dominant
- Go
- Étoiles
- 52
- Forks
- 68
- Merge moyen
- 6 h 54 min
- PR mergées (30 j)
- 10
Description
While using the CLI, I noticed that pkg/connectors/microcks_client.go uses panic(err) in several places when reading HTTP response bodies or unmarshaling JSON.
If there is a temporary network glitch (e.g., the connection drops while reading the body) or if the Microcks server returns an invalid JSON response (like a 502 Bad Gateway HTML page from a proxy), the CLI will abruptly crash and print a Go stack trace instead of handling the error gracefully.
Additionally, methods like CreateTestResult use unsafe type assertions on the parsed JSON map (e.g., createTestResp["id"].(string)), which will also cause a panic if the id field is missing from the response payload.
Expected Behavior
The CLI should catch these errors, bubble them up through the standard error return values, and print a clean, user-friendly error message to the terminal before exiting with a non-zero status code.
Actual Behavior
The CLI completely crashes with a stack trace.
Suggested Fix
We should replace all instances of panic(err) in these client methods with proper context-wrapped errors (e.g., fmt.Errorf("failed to read response: %w", err)) since the functions already have an error return type defined. We should also add the comma-ok idiom to the type assertions to ensure we don't crash on missing fields.
Guide de contribution
Ouvrir le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Piste de recherche
Commencez dans pkg/connectors/microcks_client.go en examinant les méthodes du client qui lisent les corps des réponses, désérialisent le JSON et utilisent l’assertion de type id. Remplacez les chemins provoquant un crash par des erreurs retournées et contextualisées, et gérez les champs de réponse manquants ou invalides ; le travail est terminé lorsque les erreurs inattendues de réseau, de JSON ou de structure de réponse parviennent à la CLI sous forme d’échecs propres avec un code de sortie non nul, au lieu d’une trace de pile.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Stack technique
- go
- Domaine
- api, cli, testing
- Type d'issue
- Bug
- Difficulté
- 3/5
- Temps estimé
- 1-2 jours
- Activité
- Calme
- Clarté
- Plutôt claire
- Accessibilité débutants
- 67/100