Uploaded image for project: 'Couchbase Python Client Library'
  1. Couchbase Python Client Library
  2. PYCBC-1123

Correct error message when inserting docs to non existent scope and collection

    XMLWordPrintable

Details

    • Bug
    • Status: Resolved
    • Major
    • Resolution: Incomplete
    • None
    • None
    • None
    • 3.1.2
    • 1

    Description

      a) Try and insert a document to collection that does not exist:
      Inserting doc to an non existing collection

      Expected Result - LCB_ERR_COLLECTION_NOT_FOUND (211)

      B) Try and insert a document to collection, where scope does not exists - in the case both scope and collections don't exist.
      Inserting doc to an non existing scope
      Expected Result - LCB_ERR_SCOPE_NOT_FOUND (217)

      With 3.1.2 - the error is LC_TIMEOUT

      couchbase.exceptions.TimeoutException: <Key='testdoc', RC=0xC9[LCB_ERR_TIMEOUT (201)], Operational Error, Results=1, C Source=(src/multiresult.c,316), Context=

      {'status_code': 140, 'opaque': 1, 'cas': 0, 'key': 'testdoc', 'bucket': 'testbucket', 'collection': '', 'scope': '', 'context': '', 'ref': '', 'endpoint': '', 'type': 'KVErrorContext'}

      , Tracing Output={"testdoc": {"debug_info":

      {"FILE": "src/callbacks.c", "FUNC": "dur_chain2", "LINE": 747}

      }}>

      Attachments

        Issue Links

          No reviews matched the request. Check your Options in the drop-down menu of this sections header.

          Activity

            This is a regression from older version of python SDK.

            ritam.sharma Ritam Sharma added a comment - This is a regression from older version of python SDK.
            jared.casey Jared Casey added a comment -

            Hi Ritam Sharma - This is due to a change in LCB (see CCBC-1373) that released in v3.1.2. Python v3.1.2 ships with LCB v3.1.3. This does not appear to be a regression as I understand the scope/collections APIs to still be volatile/uncommitted. Also, according to the CCBC, other SDKs operate with the same behavior.

            David Kelly - curious to your thoughts?

            jared.casey Jared Casey added a comment - Hi Ritam Sharma - This is due to a change in LCB (see CCBC-1373 ) that released in v3.1.2. Python v3.1.2 ships with LCB v3.1.3. This does not appear to be a regression as I understand the scope/collections APIs to still be volatile/uncommitted. Also, according to the CCBC, other SDKs operate with the same behavior. David Kelly - curious to your thoughts?

            I'm not sure I follow the use case Ritam Sharma. You say insert to a collection where the scope doesn't exist. Do you mean that the collection is without a scope, or literally that the code you're using expresses a scope that doesn't exist and a collection that does?

            Also, my read is that while it is retried until timeout, the error we return should still be scope/collection not found, so I tend to agree that this is a defect. This area is a bit messy because what we're aiming for is that someone can write code that creates a scope and collection and then use it in the next line. In reality, this propagates through Couchbase Server over some time and there is no good way to monitor it, so the solution we'd arrived at is when the client is asked to use a scope/collection, assume it does exist and try for a while to use it (but don't try forever).

            Jared Casey: it's true that they're uncommitted/volatile, but we should be converging to committed for this API for 3.2, so we should treat anything that comes in as an issue.

            ingenthr Matt Ingenthron added a comment - I'm not sure I follow the use case Ritam Sharma . You say insert to a collection where the scope doesn't exist. Do you mean that the collection is without a scope, or literally that the code you're using expresses a scope that doesn't exist and a collection that does? Also, my read is that while it is retried until timeout, the error we return should still be scope/collection not found, so I tend to agree that this is a defect. This area is a bit messy because what we're aiming for is that someone can write code that creates a scope and collection and then use it in the next line. In reality, this propagates through Couchbase Server over some time and there is no good way to monitor it, so the solution we'd arrived at is when the client is asked to use a scope/collection, assume it does exist and try for a while to use it (but don't try forever). Jared Casey : it's true that they're uncommitted/volatile, but we should be converging to committed for this API for 3.2, so we should treat anything that comes in as an issue.

            Update: I do see David Kelly thought it should be timeout, so perhaps my assessment is wrong. Let's let DK weigh in here.

            ingenthr Matt Ingenthron added a comment - Update: I do see David Kelly thought it should be timeout, so perhaps my assessment is wrong. Let's let DK weigh in here.
            ingenthr Matt Ingenthron added a comment - - edited

            I checked in with David Kelly and Brett Lawson on this and it is, in fact, an intentional behavioral change. The SDK team decided in the sdk-rfc that they wanted the error behavior to be deterministic. There are multiple reasons for retry, and the retry reasons will indicate that the collection/bucket could not be found. So this isn't a regression.

            Ritam Sharma, if you're trying to use this to test the actual result back from the cluster, you should be able to use the retry reason in the timeout. Glad to chat through it further if needed or check with folks in the IM channel.

            ingenthr Matt Ingenthron added a comment - - edited I checked in with David Kelly and Brett Lawson on this and it is, in fact, an intentional behavioral change. The SDK team decided in the sdk-rfc that they wanted the error behavior to be deterministic. There are multiple reasons for retry, and the retry reasons will indicate that the collection/bucket could not be found. So this isn't a regression. Ritam Sharma , if you're trying to use this to test the actual result back from the cluster, you should be able to use the retry reason in the timeout. Glad to chat through it further if needed or check with folks in the IM channel.

            People

              jared.casey Jared Casey
              ritam.sharma Ritam Sharma
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Gerrit Reviews

                  There are no open Gerrit changes

                  PagerDuty