morhidi commented on PR #217:
URL: 
https://github.com/apache/flink-kubernetes-operator/pull/217#issuecomment-1128388724

   > @morhidi You could find the following exception in the e2e tests with 
default namespace. We do not print the operator logs when `watchNamespaces` 
enabled. This also need to be fixed. 
https://github.com/apache/flink-kubernetes-operator/runs/6454327460?check_suite_focus=true
   > 
   > ```
   > Error: m2022-05-16 14:47:56,840 o.a.f.r.r.RestClient           [ERROR] 
Received response was neither of the expected type ([simple type, class 
org.apache.flink.runtime.rest.messages.DashboardConfiguration]) nor an error. 
Response=JsonResponse{json={"refresh-interval":3000,"timezone-name":"Coordinated
 Universal 
Time","timezone-offset":0,"flink-version":"1.13.6","flink-revision":"b2ca390 @ 
2022-02-03T14:54:22+01:00","features":{"web-submit":false}}, 
httpResponseStatus=200 OK}
   > 
org.apache.flink.shaded.jackson2.com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException:
 Unrecognized field "refresh-interval" (class 
org.apache.flink.runtime.rest.messages.ErrorResponseBody), not marked as 
ignorable (one known property: "errors"])
   >  at [Source: UNKNOWN; line: -1, column: -1] (through reference chain: 
org.apache.flink.runtime.rest.messages.ErrorResponseBody["refresh-interval"])
   >    at 
org.apache.flink.shaded.jackson2.com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException.from(UnrecognizedPropertyException.java:61)
   >    at 
org.apache.flink.shaded.jackson2.com.fasterxml.jackson.databind.DeserializationContext.handleUnknownProperty(DeserializationContext.java:987)
   >    at 
org.apache.flink.shaded.jackson2.com.fasterxml.jackson.databind.deser.std.StdDeserializer.handleUnknownProperty(StdDeserializer.java:1974)
   >    at 
org.apache.flink.shaded.jackson2.com.fasterxml.jackson.databind.deser.BeanDeserializerBase.handleUnknownProperty(BeanDeserializerBase.java:1701)
   >    at 
org.apache.flink.shaded.jackson2.com.fasterxml.jackson.databind.deser.BeanDeserializerBase.handleUnknownProperties(BeanDeserializerBase.java:1650)
   >    at 
org.apache.flink.shaded.jackson2.com.fasterxml.jackson.databind.deser.BeanDeserializer._deserializeUsingPropertyBased(BeanDeserializer.java:541)
   >    at 
org.apache.flink.shaded.jackson2.com.fasterxml.jackson.databind.deser.BeanDeserializerBase.deserializeFromObjectUsingNonDefault(BeanDeserializerBase.java:1405)
   >    at 
org.apache.flink.shaded.jackson2.com.fasterxml.jackson.databind.deser.BeanDeserializer.deserializeFromObject(BeanDeserializer.java:362)
   >    at 
org.apache.flink.shaded.jackson2.com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:195)
   >    at 
org.apache.flink.shaded.jackson2.com.fasterxml.jackson.databind.deser.DefaultDeserializationContext.readRootValue(DefaultDeserializationContext.java:322)
   >    at 
org.apache.flink.shaded.jackson2.com.fasterxml.jackson.databind.ObjectMapper._readValue(ObjectMapper.java:4569)
   >    at 
org.apache.flink.shaded.jackson2.com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:2798)
   >    at 
org.apache.flink.shaded.jackson2.com.fasterxml.jackson.databind.ObjectMapper.treeToValue(ObjectMapper.java:3261)
   >    at 
org.apache.flink.runtime.rest.RestClient.parseResponse(RestClient.java:529)
   >    at 
org.apache.flink.runtime.rest.RestClient.lambda$submitRequest$3(RestClient.java:512)
   >    at 
java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(Unknown 
Source)
   >    at 
java.base/java.util.concurrent.CompletableFuture$Completion.run(Unknown Source)
   >    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown 
Source)
   >    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown 
Source)
   >    at java.base/java.lang.Thread.run(Unknown Source)
   > ```
   
   This exception is not the real root cause, unfortunately, and it's 
misleading. I noticed when debugging, when the rest client is handling the 
original exception, the real response arrives, and it couldn't parse that 
response into a ErrorResponseBody. We should address this in core Flink. 
Regardless I'm planning to use a custom response class with the only 
information we need here. Overall I agree with the approach of having our own 
request/response classes in the operator that are more resilient for API 
changes. The current ones are far from ideal. We're going to hit these issues 
all the time.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@flink.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Reply via email to