Interrupted count commands don't return an error code

XMLWordPrintableJSON

    • Type: Bug
    • Resolution: Done
    • Priority: Major - P3
    • 2.5.3
    • Affects Version/s: 2.4.5
    • Component/s: Querying
    • Environment:
      Tested on Ubuntu Linux 12.04 Precise, amd64
    • ALL
    • Hide
      • Start a long-running count() (e.g. an unindexed count on a large collection)
      • Find the count in db.currentOp() from a mongo shell, and db.killOp() it
      • Inspect the error result object returned to the client, note the lack of a "code" field.
      Show
      Start a long-running count() (e.g. an unindexed count on a large collection) Find the count in db.currentOp() from a mongo shell, and db.killOp() it Inspect the error result object returned to the client, note the lack of a "code" field.
    • None
    • 3
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      If a count is interrupted (by a db.killOp()), the response to the client indicates failure and has an "errmsg" of "11601 operation was interrupted", but does not contain an error code. This is unfortunate for code that wants to determine if a failure was due to some kind of transient database failure, or deliberate termination by an administrator or sweeper (in which case it should not be retried)

      This happens because CmdCount::run() calls into runCount(ns.c_str(), cmdObj, err, errCode), but then discards the value errCode, instead of storing it into the result.

              Assignee:
              Randolph Tan
              Reporter:
              Nelson Elhage
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Created:
                Updated:
                Resolved: