Portal fails to report error in APIProduct CR containing SOAP/XSLT transform

[jameshbarton]

Describe the bug Portal fails to report an error in an APIProduct CR containing a SOAP/XSLT transform.

I’m trying to adapt the World Cities example in the Edge docs.

To Reproduce

1. Apply the APIDoc: kubectl apply -f https://raw.githubusercontent.com/jameshbarton/solo-resources/main/world-cities-soap/lib/1-apidoc-world-cities.yaml
2. Apply the APIProduct: kubectl apply -f https://raw.githubusercontent.com/jameshbarton/solo-resources/main/world-cities-soap/lib/rpt-5-apiprod-world-cities.yaml
3. Observe that the APIProduct appears to be accepted. At least there is no error message in the status of the CR. kubectl get apiproducts.portal.gloo.solo.io -n default world-cities-product -oyaml The root problem was ultimately found in the portal controller logs.

Expected behavior Malformed YAML should result in a clear Error status in the APIProduct CR.

Additional context

• Gloo Portal version 1.1.0
• Kubernetes version v1.20.9-gke.1001
• GKE context gke_solo-test-236622_us-east1-d_jimb-portal-cbp
• Gateway technology and version (Gloo Edge Enterprise v1.8.17)

[jehawley]

Specific error:

W1006 14:54:11.152619    5577 reflector.go:436] pkg/mod/k8s.io/client-go@v0.20.4/tools/cache/reflector.go:167: watch of *v1beta1.APIProduct ended with: an error on the server ("unable to decode an event from the watch stream: unable to decode watch event: v1beta1.APIProduct.Spec: unmarshalerDecoder: unknown field \"nonXmlTransform\" in transformation.options.gloo.solo.io.Transformation, error found in #10 byte of ...|le\":{}}}]}}|..., bigger context ...|e\\n\"}}}]}}}}}},\"name\":\"v1\",\"tags\":{\"stable\":{}}}]}}|...") has prevented the request from succeeding```

[jameshbarton]

@jehawley Thank you for pointing out that error in the system logs. What I was trying to get at with this ticket was the lack of an error report in a more user-visible forum, if not directly in the command output then at least somewhere like the status of the APIProduct CR. As it is, the command indicates success and the CR does not clearly indicate failure. In my role, I think a lot about how new users should expect errors like this to be fed back to the user.

How might we improve the user feedback for this kind of error condition?

[jehawley]

@jameshbarton Sure, I was posting the error for our reference (and to demonstrate that I could reproduce the issue). I think it's useful to know what error is occurring (so that we can make sure the appropriate communication of it is happening).

[jehawley]

@jameshbarton Unfortunately, a malformed CRD causes errors deep inside the libraries for interacting with Kubernetes primitives. It is arguably not the Gloo Portal controller's job to address malformed yaml, and there probably isn't a way to do it that isn't a massive hack. That is better done through setting the schema on our CRD objects. There is already an issue for this (https://github.com/solo-io/gloo-portal-issues/issues/49), so I think this one is a duplicate and can be closed?

[jehawley]

Another ticket where this behavior was noticed (and closed as a duplicate): https://github.com/solo-io/dev-portal/issues/1744

[jameshbarton]

Closing in favor of #49