Change in error code reporting in the last few days?

[Derek Chen-Becker]

I'm running a nightly (2012-04-20) of mongodb locally and if I do something wrong during an aggregate, I get back ok, errmsg, and code as properties of the result object:

{
    "errmsg" : "exception: $unwind:  value at end of field path must be an array",
    "code" : 15978,
    "ok" : 0
}

But on a fresh build from master I'm getting:

{
    "result" : [ ],
    "ok" : 0,
    "errmsg" : "-- mongod pipeline failed: { errmsg: \"exception: $unwind:  value at end of field path must be an array\", code: 15978, ok: 0.0 }"
}

It appears that the error result is being embedded inside the outer errmsg string. I'm trying a new build locally on my laptop to see if this is just strangeness on the server.

Derek

[Derek Chen-Becker]

Local build seems to be working fine. Local I'm OS X, remote is Ubuntu, so I wonder if there's some OS-specific strangeness going on...

[Eliot Horowitz]

Shouldn't be anything os specific, can you send the hash of the weird build?

> --
> You received this message because you are subscribed to the Google Groups
> "mongodb-user" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/mongodb-user/-/-zyFMOoWzjIJ.
>
> To post to this group, send email to mongod...@googlegroups.com.
> To unsubscribe from this group, send email to
> mongodb-user...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/mongodb-user?hl=en.

[Derek Chen-Becker]

The build was made from 847a67bf60807b4327b6d0d173c61ed84f522e79 on x86_64 Ubuntu 10.04.4 LTS.

Thanks,

Derek

> mongodb-user+unsubscribe@googlegroups.com.

[Tyler Brock]

Its possible that master incorporated a change made between the 20th and 24th related to the output of this message.

However, the current source seems to produce the error you are getting in the nightly build.

src/mongo/db/pipeline/document_source_unwind.cpp

118                     if (pPathValue->getType() != Array) {

119                         /* last item on path must be an array to unwind */

120                         resetArray();

121                         uassert(15978, str::stream() << unwindName <<

122                                 ":  value at end of field path must be an array",

123                                 false);

124                         break;

125                     }

Are you sure that you are on the correct branch?

-Tyler

[Derek Chen-Becker]

Interesting. I'm definitely on master, and my source matches. I'll try a re-build and see if that helps.

Derek

[Derek Chen-Becker]

Actually, I found where that error message is coming from:

I took a cursory look at Future and it looks like the failure of the pipeline is making the future fail, which in turn triggers the following code in db/pipeline/document_source_command_futures.cpp:

 96                 /* try to wait for it */
 97                 if (!pResult->join()) {
 98                     error() << "sharded pipeline failed on shard: " <<
 99                         pResult->getServer() << " error: " <<
100                         pResult->result() << endl;
101                     errmsg += "-- mongod pipeline failed: ";
102                     errmsg += pResult->result().toString();
103
104                     /* move on to the next command future */
105                     continue;
106                 }

[Chris Westin]

That hasn't changed in some time.  It sounds like what happened was you went from a non-sharded setup to a sharded setup.  The code you found in futures is wrapping the error message that came from an individual shard before returning it from mongos.  In this case, that may not look like the best thing to do, but there could be other sorts of errors that require the wrapping to indicate that it was a failure on a single shard (some classes of errors can be related to problems with the shard itself, and not with the requested aggregation operation.).  However, I would say that it is a bug that the "code" property on the error message hasn't been set in the wrapped version -- that would be the easy way to get more information beyond checking the "ok" property (which is rightly zero here).

I've submitted  https://jira.mongodb.org/browse/SERVER-5824 to make this improvement, please comment further there, watch, and/or vote.

Chris