microcks / microcks/microcks-cli
CLI crashes with panic if Microcks API returns unexpected responses
Nessuno ha ancora preso questa issue.
- Lingua principale
- Go
- Stelle
- 52
- Fork
- 68
- Merge medio
- 6h 54m
- PR unite (30g)
- 10
Descrizione
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.
Guida per i contributori
Apri la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Direzione di ricerca
Inizia in pkg/connectors/microcks_client.go esaminando i metodi del client che leggono i body delle response, fanno il parsing del JSON e usano la type assertion id. Sostituisci i percorsi che causano un crash con errori restituiti e contestualizzati, e gestisci i campi della response mancanti o non validi; il lavoro è completato quando gli errori imprevisti di rete, JSON o struttura della response arrivano alla CLI come errori puliti con un codice di uscita diverso da zero, invece di uno stack trace.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Valutazione
- Stack tecnologico
- go
- Ambito
- api, cli, testing
- Tipo di issue
- Bug
- Difficoltà
- 3/5
- Tempo stimato
- 1-2 giorni
- Stato di attività
- Tranquilla
- Chiarezza
- Abbastanza chiara
- Idoneità per principianti
- 67/100