Code change:
return lw.storage.WatchList(context.TODO(), lw.resourcePrefix, options.ResourceVersion, Everything) } <ins> // cacherWatch implements watch.Interface to return a single error type errWatcher struct { result chan watch.Event } func newErrWatcher(err error) *errWatcher { // Create an error event errEvent := watch.Event{Type: watch.Error} switch err := err.(type) { case runtime.Object: errEvent.Object = err case *errors.StatusError: errEvent.Object = &err.ErrStatus default: errEvent.Object = &unversioned.Status{ Status:  unversioned.StatusFailure, Message: err.Error(), Reason:  unversioned.StatusReasonInternalError, Code:    http.StatusInternalServerError, } } // Create a watcher with room for a single event, populate it, and close the channel watcher := &errWatcher{result: make(chan watch.Event, 1)} watcher.result <- errEvent close(watcher.result) return watcher } // Implements watch.Interface. func (c *errWatcher) ResultChan() <-chan watch.Event { return c.result } // Implements watch.Interface. func (c *errWatcher) Stop() { // no-op } </ins> // cacherWatch implements watch.Interface type cacheWatcher struct { sync.Mutex

Related discussion:
text: When attempting to fetch a resource version that is too old, the behavior of watch (for both HTTP and web sockets) changed when watch cache was enabled. The watch cache returns a 410 - without the watch cache, we return 200 and then write an "error" entry to the watch stream. This broke a client that dependent on the watch behavior, and moreover is inconsistent with other errors we set in the registry. Also, for watch over web sockets, most javascript clients will be unable to get at a 410 error from the connection, because browsers don't get access to the data. We should restore the watch cache behavior to be consistent with the previous behavior as this is a regression in API semantics. Resource without watch cache, watching too old: Resource with watch cache, watching too old:
I think this is candidate for back port to 1.2 to restore the previous behavior.
since this broke your javascript client, FYI because of watch cache
+1 for backport
hmm - we enabled watch cache in 1.1 - so this should also be broken in 1.1
It's possible that it was always nondeterministic and just depends on how fast the call to the storage layer executes. I think all of our in-tree clients will handle it either way.
I'm fairly certain this never used to behave this way, because OpenShift hasn't enabled the watch catch and we have never had a report of this until we enabled the watch cache for Kube resources just recently. , Daniel Smith wrote:
I see what you mean about ordering - etcd remote call would almost never be fast enough to beat the watch event. In practice, I suspect no one ever saw this without the watch error. Either way, for web sockets if we don't fix this clients can't get this error (the browser eats the 410 during the websocket negotiation and client code can't get access). So it's at least broken for web sockets. , Clayton Coleman wrote:
Well, it should be easy to just not wait at all, maybe? I'm OK with changing this behavior.
Although, are web clients XSS hardened? I'm not sure that we're optimizing for them currently.
If you mean CSRF, it isn't an issue with bearer token auth.