Description

The Helm backend handlers in backend/pkg/helm/ have two HTTP response handling bugs:

1. Missing return after http.Error in ListCharts (charts.go:96-98)

When listCharts() fails, the handler calls http.Error() but does not return. Execution falls through to w.WriteHeader(http.StatusOK), producing a Go runtime warning (http: superfluous response.WriteHeader call) and a corrupted HTTP response.

chartInfos, err := listCharts(filterTerm, h.EnvSettings)
if err != nil {
    http.Error(w, err.Error(), http.StatusInternalServerError)
    // BUG: missing return — falls through to write 200 OK
}

w.WriteHeader(http.StatusOK) // superfluous WriteHeader

For reference, AddRepo in repository.go handles this correctly:

if err != nil {
    http.Error(w, err.Error(), http.StatusInternalServerError)
    return // correct
}

2. Content-Type header set after WriteHeader in ListCharts and ListRepo

Both ListCharts (charts.go:104-105) and ListRepo (repository.go:238-239) set the Content-Type header after calling WriteHeader(). In Go's net/http, calling WriteHeader sends the response headers — any modifications afterward are silently ignored. This means Content-Type: application/json is never sent to clients.

// charts.go (same pattern in repository.go)
w.WriteHeader(http.StatusOK)                          // headers sent here
w.Header().Set("Content-Type", "application/json")    // too late, ignored

3. Missing structured logging in charts.go

Unlike repository.go and release.go, the charts.go handlers do not use the project's logger.Log for error reporting, making errors invisible in structured log output.

Expected behavior

• ListCharts should return immediately after sending a 500 error
• Content-Type: application/json should be set before WriteHeader in both handlers
• Error cases should use logger.Log consistently across all Helm handlers

Environment

• File: backend/pkg/helm/charts.go (lines 96-105)
• File: backend/pkg/helm/repository.go (lines 238-239)