Thanks for reporting + raising a suggested fix! Will try to look at it soon 🤞🏼

Thanks for the PR and for identifying the issue — you're right that it's a problem that ResponseErrorHandlerFunc can't set the status code when marshalling fails. However, this approach introduces some issues that I think need to be addressed before this can be merged.

I used AI to analyze every possible path through this code, and this is what it found:

Non-JSON content types lose headers and status code

The Text, Formdata, Multipart, and io.Reader template branches all contain return statements that exit the function before reaching the moved header/WriteHeader block. This means for every non-JSON content type:

• Content-Type header is never set
• Custom response headers are never set
• WriteHeader is never called (net/http defaults to 200 on first Write, so any non-200 status code would be lost)

This would be a breaking regression for all non-JSON strict server responses.

JSON path: headers set after writing the body are ineffective

For the JSON path, json.NewEncoder(w).Encode(...) writes directly to the http.ResponseWriter. In Go, the first call to w.Write() implicitly triggers WriteHeader(200) and flushes headers. So the w.Header().Set("Content-Type", ...) and w.WriteHeader(200) calls that follow the Encode are effectively no-ops (and WriteHeader will log a "superfluous response.WriteHeader call" warning).

The fix doesn't fully achieve its stated goal

Since json.NewEncoder(w).Encode() writes directly to w, if it writes any bytes before encountering an error, an implicit 200 status and partial body are already on the wire. The error handler can't un-send that.

Suggested approach: encode to a buffer first

To properly fix this, the body should be encoded to a buffer before anything is written to the ResponseWriter. For example, for the JSON case:

var buf bytes.Buffer
if err := json.NewEncoder(&buf).Encode(response); err != nil {
    return err  // nothing written to w yet, so error handler can safely set status
}
w.Header().Set("Content-Type", "application/json")
w.WriteHeader(200)
_, err := buf.WriteTo(w)
return err

This ensures:

1. If encoding fails, nothing has been written to w, giving ResponseErrorHandlerFunc full control over the response status
2. Headers and status code are set before the body is written
3. Content-Type and custom headers are correctly applied

The downside:
We now need to buffer the entire encoded response in memory, where it was possible to stream it in the past.

@greptileai

Greptile Summary

This PR fixes a critical bug where generated Visit*Response functions called w.WriteHeader(...) before marshalling the response body, preventing ResponseErrorHandlerFunc from changing the HTTP status code when encoding errors occurred.

Key changes:

• JSON responses (template lines 80–90): encoding is now buffered into bytes.Buffer first; headers and WriteHeader are only written after successful encode, allowing marshalling failures to be caught before any response bytes commit.
• Formdata responses (template lines 92–102): runtime.MarshalForm is now called upfront and errors before WriteHeader, matching the JSON fix.
• New test package (internal/test/issues/issue-1963): covers happy-path Visit calls for all five content types and two error-path integration tests confirming ResponseErrorHandlerFunc can set status 500 when JSON encoding or form marshalling fails.
• Generated files throughout the test suite are updated to reflect the new buffered pattern.

Known limitations: Text, Multipart, and binary (io.Reader) responses still call WriteHeader before writing the body. Multipart is particularly notable because the user-supplied callback executes after WriteHeader, so an error in that callback still cannot be intercepted by the error handler. These are harder to buffer (multipart streams incrementally, binary is an io.Reader) and were out of scope for this PR, but documenting this gap would help clarify architectural decisions for future maintainers.

Confidence Score: 4/5

• Safe to merge. The core fix correctly buffers JSON and Formdata encoding before headers are committed, directly solving the reported issue. Regression tests validate the fix works end-to-end.
• The fix is sound and well-tested. JSON and Formdata error-path tests confirm that ResponseErrorHandlerFunc can now set status codes when encoding fails. The main deductions are: (1) the error-path test uses a hand-written Visit implementation rather than the generated one, slightly weakening coverage of the exact template output; and (2) Multipart, Text, and Binary responses remain inconsistent with the same architectural issue, though that's documented as intentionally out of scope.
• pkg/codegen/templates/strict/strict-interface.tmpl — the Multipart branch (lines 103–127) still calls WriteHeader before the user callback, mirroring the original bug. Documenting this remaining gap would clarify the intentional architectural boundary.

_{Last reviewed commit: 2b56060}

@greptileai