Read RFC 7807 title and detail through their pointers in FormatErrorMessage

[midwell]

The defect

The generated models declare the RFC 7807 members as *string with omitempty, and
FormatErrorMessage formatted the field's Interface() with %s. On a pointer that renders the
address, so the text the function exists to surface is replaced by it in
GenericOpenAPIError.RawError — which is what callers log and what the SBI error paths propagate.

Both states were wrong, not only the populated one:

403 Forbidden %!s(*string=0x14000123456) (%!s(*string=0x14000123460))
403 Forbidden %!s(*string=<nil>) (%!s(*string=<nil>))

The second is the more common of the two. Every member is omitempty, so a model carrying only a
cause has both nil, and the old code printed the nils rather than nothing. The check it used,
field != (reflect.Value{}), also cannot tell a field that is absent from one that is present
and unset — of the three states a member can be in, only one was handled.

Observed rather than inferred: the first line above is from a live SMF rejection reaching an AMF,
which logged S-NSSAI[sst: 1, sd: %!s(*string=0xc00103d2c0)].

The fix

problemDetailsString follows a single level of pointer indirection and returns the empty string
for all three "nothing to say" states — no such field, a nil field, an empty one. The message is
then assembled from the members that have something in them, so an unset detail no longer
contributes an empty ().

Non-pointer string members keep their existing output. The one deliberate behaviour change is
that a member with nothing in it is omitted rather than rendered, which is the point of the fix.

It also removes two panics on the unconditional Elem(): an untyped nil ("on zero Value") and a
model passed by value ("on struct Value"). Neither is reachable from the generated API methods —
all 4633 call sites pass &v — so that part is hygiene for an exported reflective helper rather than a
live defect, and it costs nothing, because reading through a pointer member needs the Kind checks
in any case. A typed nil pointer was already safe and still is.

Deliberately not done: returning only the status. That removes the symptom by discarding the
detail, which is the information the function exists to carry.

No test in this package

Deliberately none, following the review of #176: *_test.go names here are the generator's own
output slots, so a hand-written test in this package is silently overwritten by a regeneration
rather than merely deleted. Assertions for this behaviour belong with the consumer.

The fix was mutation-verified before that test was dropped, against the previous implementation:

case	before the fix
populated *string members	reports the address in the message
the seven empty-state cases	five wrong; the two right ones are a model with neither member, and non-pointer members both set
untyped nil model	panics, "on zero Value"
model passed by value	panics, "on struct Value"

Note for whoever regenerates

The buggy body is verbatim stock output from the generator's go/client.mustache (checked
against 7.24.0), so a regeneration reinstates it unless that template is fixed as well. The
upstream template carries the same two faults for every Go client it generates.

This file has already diverged from stock in six ways, so it is in practice hand-maintained:
exported RawBody/RawError/RawModel in place of the unexported body/error/model, any
for interface{}, an exported FormatErrorMessage, and AsGenericOpenAPIError plus the generic
ErrorModel[T], neither of which exists in the template at all.

Verification

go test -race ./... -count=1, staticcheck v0.8.1, golangci-lint v2.13.2 (in Docker, with the
repo config), gci v0.14.0, gofmt, gofumpt and reuse lint are all clean. The commit was
extracted into a clean tree with git archive and rebuilt and re-checked there, not only in the
working tree.

VERSION drops -dev to 2.2.3, following #176, so the fix is consumable by the network functions
on merge rather than waiting for a separate release PR.

🤖 Generated with Claude Code

https://claude.ai/code/session_01GyNr6vp6JaxxzPyVcuHXTf

[midwell]

Closing this in favour of a fix to the template it is generated from.

generic_error.go carries the generator's DO NOT EDIT header, and the buggy body is verbatim
stock output from openapi-generator's go/client.mustache — still unchanged on that project's
master, so every Go client it generates has the same fault. A hand edit here would be reinstated
by the next regeneration, and it would leave the defect in place for everyone else.

Fixed at the source instead: OpenAPITools/openapi-generator#24853, which also closes their
open bug report OpenAPITools/openapi-generator#20553 describing exactly this symptom
(%!s(*string=0x...) in place of the message).

No test was added here either way: *_test.go names in this package are the generator's own output
slots, so a hand-written test would be silently overwritten rather than merely deleted — the same
point raised in the review of #176. Assertions for this behaviour belong with the consumer.