Misleading comments and small redundancies in the core path

Offen Anfängerfreundlich
  • Stimmt etwas nicht?
#329 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
2/5
Geschätzter Aufwand
Ein halber Tag
Anfängerfreundlichkeit
75/100
Issue-Typ
Refactoring
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
go
Bereich
cli, networking

Rechercherichtung

Beginne mit den sieben genannten Zeilen: den veralteten JSON-Kommentaren in internal/output/writer.go und internal/tui/model.go, dem Log-Aufruf resolveWithLog in internal/dns/resolver.go, dem doppelten Aufruf von validateArgs in main_session.go und main.go sowie den beiden fmt.Fprintf-Warnungen in tuiOptions. Fertig ist, wenn die Kommentare gestreamte Ausgabe beschreiben, -v bei einem NODATA-Ergebnis nicht mehr Error: <nil> ausgibt, die doppelte Validierung entfernt ist und die TUI-Warnungen über diag laufen. Prüfe mit make test unter Verwendung von -simulate oder des lokalen Testservers, nicht einer Live-Domain.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

good first issue severity: low tech-debt

Summary

A checklist of small items: three comments that still say JSON output is buffered, a verbose log line that labels a definitive negative as a failure with Error: <nil>, a validation call that runs twice, and two TUI warnings that bypass the diagnostics writer.

Where

  • internal/output/writer.go:28
  • internal/tui/model.go:329
  • internal/tui/model.go:346
  • internal/dns/resolver.go:479
  • main_session.go:288
  • main.go:304
  • main_session.go:230

Details

Checklist, each item read at the cited line:

  • writer.go:28: "FormatJSON buffers results and emits a single JSON array at completion". Since #181 it streams each element (writeJSONElement, writer.go:255-284); the comment on Emit at 175-178 says so correctly.
  • tui/model.go:329-330 and 346-347: "finalize structured output so buffered JSON/CSV is written" and "buffered JSON array emitted": same stale description of JSON.
  • resolver.go:478-479: l.Logf("Failed to resolve: %s (Error: %v) in %s", domain, err, elapsed) also runs when the lookup succeeded with no records of the requested types (err == nil, the NODATA case Resolve handles at 500-505), so -v prints Failed to resolve: x (Error: <nil>) for a definitive negative.
  • main_session.go:288 calls validateArgs, and validateFlags (called at 318) calls it again as its first statement (main.go:304). The second call can never fail.
  • main_session.go:230 and 240: tuiOptions writes its two warnings straight to stderr with fmt.Fprintf, bypassing the diag writer built ten lines earlier (main_session.go:162), so -tui -log-format json emits plain text lines among JSON ones.

Impact

Readers are told JSON output is held in memory when it is not (relevant to anyone reasoning about memory or partial output), verbose logs label negatives as failures, and two small inconsistencies add noise. None changes results.

Suggested fix

Reword the three comments to "streamed as array elements; Finish closes the array". In resolveWithLog, branch on err == nil and log "No records: %s (%s) in %s". Drop the validateArgs call from validateFlags or from configure. Route the two TUI warnings through diag.Notice.

Acceptance criteria

  • Each checklist item under Details is fixed
  • -v no longer prints Error: <nil>

Getting started

  • Relevant files: internal/output/writer.go, internal/tui/model.go, internal/dns/resolver.go, main_session.go
  • How to run tests: make test (or go test ./...). Tests must stay hermetic: use -simulate, -simulate-zone or the local DNS test server, never a live domain.
  • Related docs: docs/DEVELOPER_GUIDE.md, docs/ARCHITECTURE.md

Filed by repo-audit/full-audit at d0c56f0. Severity: low. Effort: S. audit-key: tech-debt|internal/output/writer.go|comments

Vorherrschende Sprache
Go
Sterne
1
Forks
1
Ø Merge
6 Std. 42 Min.
Gemergte PRs (30 T.)
7

Entwicklungsumgebung

In Codespaces öffnen

Startet den Dev-Container des Projekts im Browser, mit Ihrem eigenen GitHub-Konto.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus TMHSDigital/subenum

Alle Issues in TMHSDigital/subenum

Ähnliche Issues

Weitere Issues zu Go

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.