| Name | Modified | Size | Downloads / Week |
|---|---|---|---|
| Parent folder | |||
| Goa v3.25.1 source code.tar.gz | 2026-02-16 | 1.3 MB | |
| Goa v3.25.1 source code.zip | 2026-02-16 | 2.3 MB | |
| README.md | 2026-02-16 | 5.2 kB | |
| Totals: 3 Items | 3.7 MB | 0 | |
Highlights
- HTTP route tagging fix (otelhttp): v3.25.1 completes the
r.Patternroute tagging work from v3.25.0 sootelhttp(v0.65.0+) reliably records thehttp.routespan attribute and metric route when used as a mux middleware (mux.Use(otelhttp.NewMiddleware(...))). (#3898) - Better DSL error messages: validation errors include
file:linelocations pointing to the offending design declaration, making it much faster to find and fix issues in large Goa designs. (#3895) - Mixed unary + SSE results: services can define both a unary
Resultand aStreamingResulton the same method with distinct types — the generated HTTP handler performs content negotiation based on theAcceptheader. (#3883)
What changed
HTTP runtime
r.Patternauto-populated (and visible to middlewares): the default muxer captures the original Goa route pattern (before Chi wildcard rewriting) and setsr.Pattern = "METHOD /path"following the Go 1.22+ convention. v3.25.1 ensures this happens early enough that middlewares registered viaUse()(includingotelhttp.NewMiddleware) can readr.Patternat span-start time to populate thehttp.routeattribute. (#3897, #3898)
Eval / DSL
- Validation error locations:
Validate()-phase errors now derivefile:linefrom the expression's DSL function pointer usingruntime.CallersFrames, robust to inlining. Both DSL-time and validation-time errors benefit. (#3895, #3890)
Codegen
- Mixed unary + SSE: generated handlers perform
Accept-based content negotiation; the generated client exposes a split API (Methodfor unary,MethodStreamfor SSE). A non-nil discard stream implementation is passed in unary mode so service code can use the stream parameter without nil guards. (#3883) - OneOf in ResultType views: union helper types are now emitted in the
viewspackage when referenced by view-projected types, fixing build failures forOneOfinsideResultType. (#3884) - Composite client response decoding: unnamed array/map HTTP client response bodies now decode directly into the concrete wire type instead of generating endpoint-scoped wrapper aliases, fixing build failures when multiple endpoints share a structural type. (#3888)
- WebSocket upgrade error persistence: upgrade failures are now stored on the server stream struct so subsequent
Send/Recvcalls reliably return the error instead of panicking on a nil connection. (#3885) - HTTP client array payload codegen: fixed deduplication of request body builder functions when multiple methods use
ArrayOf(...)payloads with different element types. (#3879)
Upgrade notes
This release changes generated code. After upgrading, regenerate and review the diff:
:::bash
go get goa.design/goa/v3@v3.25.1
# then run your normal generation flow (goa gen / go generate)
OpenTelemetry route tagging
- Recommended: register
otelhttpas a mux middleware so it can readr.Patternat span-start time:
go
mux := goahttp.NewMuxer()
mux.Use(otelhttp.NewMiddleware("service"))
- If you wrap the mux externally with
otelhttp.NewHandler(mux, ...),otelhttpstarts the span before it calls into the mux, sor.Patternis not available at span-start. In that setup, use theotelplugin (it setshttp.routedirectly on the active span inside each generated handler).
Full changelog
- #3898 http: set r.Pattern in ServeHTTP before middleware dispatch
- #3879 fix: http client codegen for multiple array-type payloads
- #3883 codegen: support mixed unary + SSE results
- #3884 codegen: generate OneOf unions in views package
- #3885 http/codegen: persist websocket upgrade errors
- #3888 http/codegen: decode composite client responses without wrappers
- #3890 eval: report validation error locations
- #3895 eval: report validation error locations (refinement)
- #3897 http: set r.Pattern on dispatched requests for automatic route tagging
Compare: https://github.com/goadesign/goa/compare/v3.25.0...v3.25.1
Thank you to @abocim for contributing #3879!