arangojs: Sporadic cursor not found error (1600 error code)

I have a troublesome issue where i’m sporadicly getting the dreaded cursor not found error. What i’ve tracked down is that it only seems to happen on queries that return more than 1K records.

Here’s the error i’m getting:

{ ArangoError: cursor not found
     at new ArangoError (/usr/src/app/node_modules/arangojs/lib/async/error.js:71:21)
     at Object.resolve (/usr/src/app/node_modules/arangojs/lib/async/connection.js:243:32)
     at _hosts.(anonymous function) (/usr/src/app/node_modules/arangojs/lib/async/connection.js:122:26)
     at IncomingMessage.res.on (/usr/src/app/node_modules/arangojs/lib/async/util/request.node.js:48:21)
     at IncomingMessage.emit (events.js:185:15)
     at endReadableNT (_stream_readable.js:1106:12)
     at process._tickCallback (internal/process/next_tick.js:178:19)
   isArangoError: true,
...

Here’s the relevant code which sporadically causes this error:

console.log('query = ', query)
  db.query(query)
    .then(cursor => {
      // console.log('cursor = ', cursor)
      return cursor.each(result => {
        if (result !== null && result.resourceType !== 'Statement' && result.resourceType !== 'StatementGroup') {
          results.push(result)
          auditRead(req, result)
            .then(() => {
              return Promise.resolve()
            })
            .catch(err => {
              return Promise.reject()
            })
        }
      })
    })
    .then(() => {
      results = Bundle.wrapInBundle(ReqHelpers.getBaseUrl(req), results, BundleType.searchSet)
      results = FhirHelpers.stripArangoAttributesFromBundle(results)
      return res.status(HttpStatus.OK).send(results)
    })
    .catch(err => {
      console.error('err in $everyting catch = ', err)
      if (err.isArangoError) {
        let response = FhirHelpers.generateErrorObject(IssueType.exception, req.path, err.response.body.errorMessage)
        return res.status(err.response.statusCode).send(response)
      } else {
        let response = FhirHelpers.generateErrorObject(IssueType.exception, req.path)
        return res.status(HttpStatus.INTERNAL_SERVER_ERROR).send(response)
      }
    })
}

/**
 * Save audit information for a read
 * @param  {Object} req       The request object
 * @param  {Array}  resources array of resources
 * @return {[type]} [description]
 */
function auditRead (req, resources) {
  return new Promise((resolve, reject) => {
    let event = FhirHelpers.generateAuditEvent(req, FhirHelpers.typeOfAction().read)

    const auditEvents = db.collection('auditevents')
    const auditEdges = db.collection('auditedges')

    auditEvents.save(event)
      .then(info => {
        // If it's an array, save every record as an auditevent, else save the single record as an auditevent
        if (Array.isArray(resources.entry)) {
          for (let resource of resources.entry) {
            let eventEdge = {
              _key: uuidv4(),
              _from: info._id,
              _to: 'clindocs/' + resource.resourceType + '$' + resource.id 
            }
            auditEdges.save(eventEdge)
              .then(edgeInfo => {
                return Promise.resolve()
              })
              .catch(err => {
                return Promise.reject(err)
              })
          }
        }

        return Promise.resolve()
      })
      .catch(err => {
        return Promise.reject(err)
      })
  })
}

I’m using arangojs version 6.6.0

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Comments: 23 (11 by maintainers)

Most upvoted comments

@toymachiner62 : yes, 3.3.18 was skipped for some internal reasons. 3.3.19 contains everything that was supposed to be released with 3.3.18 plus more bugfixes. So yes, 3.3.19 contains the fix.

Ok thanks. With 3.3.14 I wouldn’t expect this to happen, except if the cursor has timed out meanwhile. By default, cursors have a timeout of 30 seconds. If something in the client application takes more time than 30 seconds between originally “ordering” a cursor and making a follow-up request to fetch more data from the cursor, then the issue may also occur. But I was originally assuming this is not the case.

Sorry, I am not 100% sure about your actual setup still. The files in https://github.com/arangodb/arangojs/issues/573#issuecomment-424450014 use an ArangoDB version 3.1, which is relatively old. With that version it is still possible to get intermittent “cursor not found” issue when multiple coordinators are in use and client application requests are sent to any coordinator in a round-robin fashion using a load-balancer. The reason for this is that cursor state is stored locally on coordinators, and if follow-up requests for a specific cursor are sent to a coordinator that does not know anything about that cursor, it will return HTTP 404. Later versions of ArangoDB (from 3.3.14 onwards) support forwarding these requests transparently, so it should work in that setup. It should always work with cursors that return 1000 or less results, because 1000 is the default batch size of cursors, and any results <= 1000 documents will be handled with a single request/response, without any follow-up requests necessary.

So upgrading to 3.3.14 or higher should help.