IndexNotFoundException not raised when QueryIndexManager.watchIndex called with a non-existent index

I looked a this and the SDK is not throwing an exception if no indexes were returned for the operation, it just exits the method with a break;.

Ok that does sound like a legitimate SDK bug, so I'll rename this ticket accordingly.

The Driver seems to read SDK_COUCHBASE_EXCEPTION even though the exception field is not set when returned by the performer.

Oh!  That's weird.  Probably because SDK_COUCHBASE_EXCEPTION is the first in CouchbaseExceptionType, and the driver is incorrectly assuming that such an exception has been returned (result.getException().getCouchbase()).  Would be safer for it to use ExceptionValidator.assertCouchbaseExceptionResult.  I'll make that change, it's a quickie.  Update: Gerrit.

Correct again, this has nothing to do with NCBC-3397. I removed the ticket link.

I looked a this and the SDK is not throwing an exception if no indexes were returned for the operation, it just exits the method with a break;. So the operation succeeds and SetSuccess(result) is returned. The Driver seems to read SDK_COUCHBASE_EXCEPTION even though the exception field is not set when returned by the performer.

Sorry I'm confused - KV shouldn't be involved here at all, or a 2.5 second timeout. It's a query index management test so the management timeout should apply.

This still happens yes, it's due to an SDK problem where KV operations timeout using the default 2.5s token for certain parts of their inner operations. It still hasn't been attributed to a sprint since it will require refactoring of pretty much all operations, but we do need to fix this.
I tested it again but it's not eventual consistency just SDK.

Does this still happen?  What's the full exception raised from the SDK including the error context?  We have had some server consistency issues (and just a legit test bug) with QueryIndexManagerTest.watchingAbsentIndexThrowsException in the past.  Actually it wasn't this specific test.  But still, would be good to know what failure is returned.