Never understood why methods with this purpose are called "WriteHeader" in golang-world. You're not writing a "header" (as in a request or response header), you are writing a status code (or status line). I find the name confusing.

But I guess this implements http.ResponseWriter so 🤷

Yeah this is purely to match up with the standard library http.ResponseWriter interface so we don't really control it 😢

What's the purpose of Location? Specifically, is it a source code location? Because an end-user won't be able to do anything with that information (other than providing it in a support ticket, in which case some sort of error code would probably be better anyway).

I've added some additional documentation. This is actually the location in the input as a JSONPath type link and can refer to request parameters (path/query/header) or the request body. For example:

{
  "status": 400,
  "title": "Bad Request",
  "detail": "Request input did not pass validation",
  "errors": [
    {
      "message": "Could not parse int",
      "location": "path.thing-id",
      "value": "abc"
    },
    {
      "message": "Field is required",
      "location": "body.tags[1].description"
    },
    {
      "message": "Must match pattern ^[a-z0-9-]+$",
      "location": "body.slug",
      "value": "foo_bar"
    }
  ]
}

I actually find that very annoying, because I think that if a single test fails you'll get log spew from all the tests (making debugging harder). This would be even worse for table-drive tests where maybe just one case is failing. I would like to be able to at least have the option to not attach a logger.

You have a couple of options for this:

1. Call humatest.NewRouter for each test in the table, then you get only the single failing log output.
2. Ignore the humatest package and just do huma.New instead and you get a blank router without any middleware.

Are there any examples of this in the existing code? I'd be good to see a setup that could be used to demonstrate this for future testing.

Would be nice to see an example of how this integrates with the datadog tracer API.

I think this is all you have to do:

// Start a Datadog tracer, optionally providing a set of options,
// returning an opentracing.Tracer which wraps it.
t := opentracer.New(tracer.WithAgentAddr("host:port"))

// Use it with the Opentracing API. The (already started) Datadog tracer
// may be used in parallel with the Opentracing API if desired.
opentracing.SetGlobalTracer(t)

https://github.com/DataDog/dd-trace-go/blob/v1/ddtrace/opentracer/example_test.go#L15-L23

which run before operation handlers.
Is my understanding correct that the middleware executes to completion, then the operation handler is executed?

No change requested, just looking to understand: I am mentally contrasting it with a gRPC interceptor where the middleware calls the handler so it can also take action on the handler response.

It's the same concept. Each middleware takes a next handler and calls next.ServeHTTP(w, r) on it, and at the end of the chain next is just the handler function itself.

This isn't a very informative type name; what is meant by hcontext?

The name context is taken by a standard library package, so we append the name of this package. I guess that means it stands for "Huma context". It was just a way to prevent shadowing and is an internal implementation detail of the public huma.Context interface.

It's a pretty common pattern but by no means the only way to handle this. Open to other naming suggestions.