snjypl commented on issue #21087: URL: https://github.com/apache/airflow/issues/21087#issuecomment-1121271456
@ecerulm sorry, but it is not how watch works. if you start a watch with an old resourceVersion it **WILL** always give you 410 error. that is the expected behaviour. > When the requested watch operations fail because the historical version of that resource is not available, clients must handle the case by recognizing the status code 410 Gone, clearing their local cache, performing a new get or list operation, and starting the watch from the resourceVersion that was returned. in short: if you get 410, start a fresh watch. don't bother about the recent resoureVersion, because whatever maybe the resourceVersion that your application is having it would still be old. you can't have a fresher resource version than the kube client watcher. maybe looking at the unittest for the bookmark events might help: https://github.com/kubernetes-client/python/blob/f379bbabf33f239f49b0e1b7652b6212f3960910/kubernetes/base/watch/watch_test.py#L170-L204 > thats the point to simulate an already expired resource version, like it would happen if there was a watch disconnect due to some network issue, there was 5 minutes network disconnect from airflow to k8s api, until the next watch could actually be performed, then the resource_version will be already expired. In order to simulate that quickly I use `resource_version=1` In this scenario, you need to start a new watch without resourceVersion or resoureVersion="0". when you pass any other resourceVersion, you can asking to start from that specify version and it does not exist in the case you will get 410 error. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
