Change:
return fmt.Sprintf("object %v does not implement the protobuf marshalling interface and cannot be encoded to a protobuf message", e.t) } <ins> func (e errNotMarshalable) Status() metav1.Status { return metav1.Status{ Status:  metav1.StatusFailure, Code:    http.StatusNotAcceptable, Reason:  metav1.StatusReason("NotAcceptable"), Message: e.Error(), } } </ins> func IsNotMarshalable(err error) bool { _, ok := err.(errNotMarshalable) return err != nil && ok

Discussion:
/kind bug What happened: Sent a request for an aggregated resource (sample-api wardle/flunders). Response was a 200 status code and an error message saying the response could not be given. What you expected to happen: We should have an error status code. How to reproduce it (as minimally and precisely as possible): 1) Set up sample-apiserver. 2) curl -k -v -XGET -H "User-Agent: kubectl/v1.8.0 (linux/amd64) kubernetes/" -H "Accept: application/vnd.kubernetes.protobuf" -H "Authorization: Bearer <token" https://<aggregator 3) Response < HTTP/1.1 200 OK < Content-Length: 173 < Content-Type: application/vnd.kubernetes.protobuf < Date: Tue, 08 Aug 2017 22:57:37 GMT < k8s v1Status  Connection to host 35.193.112.40 left intact Failure~object v1alpha1.FlunderList does not implement the protobuf marshalling interface and cannot be encoded to a protobuf message"0" Anything else we need to know?: Environment: Kubernetes version (use ): 1.8 Cloud provider or hardware configuration**: GCE OS (e.g. from /etc/os-release): Debian GNU/Linux 7 (wheezy) Kernel (e.g. ): 3.16.0-4-amd64 Install tools: Others:
/sig api-machinery
I expect that's a shortcoming of the example server, not the aggregator itself
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or .

/lifecycle stale
/remove-lifecycle stale /lifecycle frozen
Hello, I'd like to take a look into this as my first contribution.
/assign
GitHub didn't allow me to assign the following users: tristanburgess. Note that only and repo collaborators can be assigned. For more information please see <detailsIn response to : /assign Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Looking into this so far, I'm able to reproduce the issue, and also that using does serialize correctly: There are potentially two separate considerations out of this as far as I can tell (in addition to the original issue): 1) 's example resource types do serialize JSON correctly, but does not appear implement protobuf serialization. I still need to confirm that it definitely isn't implemented (the error conditions at play may be too general to pick up a more specific error in play). There's a example resource type in addition to . Would be worth confirming the behavior of that type as well. If desired, I can also file a feature request to implement protobuf serialization for the example resource types. 2) I will investigate separately if disabling the JSON serial/deserial impl has a similar effect as this bug, or a more desirable effect; either way, would be good to unify the two behaviors. Lumped in with this part of the investigation will be to figure out what's handling the error from , and ultimately giving the 200. In terms of the actual status code we want to return, would make sense for this? Looking at the doc above it seems to fit the situation that the requestor requests a response format that isn't servable. It looks like completely invalid formats to the API do serve a 406. Any thoughts?
Pertaining to 2), JSON serialization appears to be baked in to the API as the default, so there really isn't a similar error for it. A JSON marshalization fault at the apimachinery level currently would prevent the apiserver from starting up successfully. Therefore, only have to worry about protobuf for this.
For 1), .proto definitions definitely weren't created for the extension API resource types. I generated them and confirmed that API response was successful after that.

I'll file a separate ticket/PR for the addition to the sample APIs after this issue is fixed.
I had a starting implementation that successfully returned a 406 on protobuf marshalling definition not implemented (), but on running unit tests I stumbled upon a larger problem. There's an order of operations issue which is preventing http status code from being handled properly with both serialization encode success and serialization encode failure between apiserver and apimachinery. can only be called once. will call if is not called explicitly beforehand. In , is called with the statusCode passed in before calling ,which generates a serialized response body with machinery in . The problem in and child methods is if encoding fails, regardless of the failure reason. We have already called before , so the error handler in , , has no net effect on the status code in the response, even though it generates an appropriate error and tries to call with the new status code. The specific case of encode failing can be resolved by calling only after . If there's an error during encoding, no full will occur such that the default 200 status code will be set in place. Thus, would successfully write the new error code resultant from encode failure, which includes handling of the protobuf error enhancements I have . The catch is, this change would now cause successful encode to return the wrong status code, because our , and even Golangs built in package (which is used for our JSON encoding), will both translate and the data, which in turn will call , because we haven't called ourselves yet. The solution here is likely to move header modifications closer to time, to allow for this differentiation between original and a potential resultant from an encode failure. Two questions I'm currently weighing are: 1) If the original status code is failure (4xx, 5xx), and encoding also fails, what's the right status code and response? 2) If we move closer to , such that pre- errors can be handled with the correct status, but itself fails, we still have a problem where we've already called , so we can't further change the status code. What's the correct behavior here? Possibly to return the original status code but generate a raw text response body instead.