Goa v3.34.0

Goa v3.34.0 adds first-class support for URL-encoded form requests, gives transport plugins two new generator building blocks, and fixes a series of generation and runtime issues reported against the v3.31 generator rewrite. If you use result views with collection or map bodies, JSON-RPC path or query bindings, renamed credential fields, or gRPC cancellation, this release is for you.

Highlights

URL-encoded form requests (#4030). A new FormRequest() DSL call selects application/x-www-form-urlencoded for an ordinary HTTP endpoint, and Goa generates the client encoder, server decoder, validation and OpenAPI description from the designed body fields. OAuth token endpoints and other form APIs no longer need handwritten codecs. Bodies may contain primitives and primitive arrays; arrays use repeated keys. Adding FormRequest() to an existing endpoint requires regenerating and deploying client and server together.

Transport plugins can reuse Goa's URL parameter validation (#4027). HTTPEndpointExpr.ValidateParams exposes the same path and query checks that HTTP and JSON-RPC endpoints use, so a plugin method sharing a service URL reports the same precise errors instead of an unrelated planning failure.

Generator plugins can require server dependencies (#4028). A plugin can declare a constructed dependency such as a configured *http.Client for a native HTTP or JSON-RPC server. Goa adds the constructor argument, retains the value on the server, and wires the generated example startup through an application factory. Nothing changes unless a plugin declares a dependency.

Fixes

• Client result constructors compile again when a result type with views maps a collection or map attribute to the response body with Body("attr"), a regression since v3.31.0 (#4032, reported in #4031).
• Generated HTTP bodies and OpenAPI agree when a service type sets an internal JSON name with Meta("struct:tag:json:name", ...) (#4029).
• Explicit Body(func() { ... }) bodies with only primitive fields or arrays now get a generated body type and client constructor, so form clients for mapped fields such as Attribute("label:display_name", String) compile and validate required mapped fields before constructing the payload (#4033).
• Mapped URL parameters such as Param("organization_id:organization") keep the payload name and the URL name separate across HTTP and JSON-RPC (#4026).
• Generated gRPC clients and servers report cancellation and deadline expiry with the standard Canceled and DeadlineExceeded codes instead of Unknown (#4025). Regenerate clients and deploy them before or with servers.
• JSON-RPC transports preserve typed path inputs and explicit HTTP query bindings instead of producing undeclared variables or missing client inputs (#4024, #4022).
• JSON-RPC servers run HTTP middleware installed with Server.Use on every entry point, including mounted and directly served services (#4023).
• Authentication code references credential fields renamed with Meta("struct:field:name", ...), fixing a compile failure in generated services (#4021). Authentication callback errors are returned unchanged (#4020, #4019).
• A service returning a result that fails selected-view validation is reported as a server fault rather than a caller input error (#4018).

Upgrade notes

The upgrade guide has a v3.34.0 section for each change above with deployment order and rollback. Regenerate your services with the new CLI. Deploy regenerated gRPC clients before or together with servers so cancellation statuses are preserved end to end. Form request endpoints require matching client and server generation.

Contributors

Thanks to @pbennett for the precise report and minimal design that pinned down #4031.