gen_openapi_errors

Overview ¶

gen_openapi_errors generates OpenAPI default responses for each operation.

The error set of a service method is inferred from the implementation by erroranalysis, which follows the error value through the call graph. The "errors:" doc comments on the service interfaces are no longer the source of truth; where one disagrees with the code, the generator reports the drift and the code wins.

Bootstrapping a pruned tree ¶

That inference type-loads the module, and the module does not type-check until ogen has written api/generated — which ogen produces from a spec whose endpoints $ref the very files written here. On a tree that still holds its generated output the cycle is invisible; on a pruned one no directive order resolves it, because it closes through this generator's own chain.

So the generator breaks it itself, rather than leaving it to whoever invokes it. When api/generated is absent it runs two prerequisites before analyzing:

• the enumer directives, because the analysis also needs their output and `go generate ./...` reaches internal/ only after api/;
• the ogen directive, over a placeholder spec written here that gives every operation every known error code. That spec is wrong but complete, which is all ogen needs, and it is deliberately a superset: whatever types the honest pass makes ogen generate, the placeholder made it generate too.

The analysis then runs against a module that compiles, the real sets overwrite the placeholders, and the ogen directive that follows this one in api/generate.go regenerates the client from them. Both prerequisites shell out to `go generate -run`, so their commands stay declared in one place instead of being copied here.

This is why bare `go generate ./...` and `moon run server:generate` both work from a pruned tree: neither of them knows about the cycle.

Paths are calculated relative to this generator's location:

• Domain: ../../../internal/domain
• Service: ../../../internal/service
• OpenAPI: ../../openapi