Why does this MongoDB insert (from Meteor) fail with an "Internal Server Error [500]"?

help
1

My attempt to insert a record into a MongoDB from a Meteor app is failing.

Here is my HTML/Template:

    
      

        
Add a Job/Location

        
          Log In
          Designation for Job/Location
          
          Save Job/Location

Here is the client-side JavaScript:

    Template.addJobLoc.events({
          'click #btnSaveJobLoc': function(event, template) {   
            var username = Session.get("username");
            var jobloc = template.find('#textJobLoc').value;
            Meteor.call('insertJobLocation', username, jobloc, function(err) {
                  if (err) {
                    Session.set("lastErrMsg", err.message);
                  } else {
                    alert(jobloc + ' inserted');
                    $('#textJobLoc').val("");
                    $('#textJobLoc').focus();
                  } // else
            }); // Meteor call
          } // submit form event
    });

And here is the server-side JavaScript (in a .js file of my project’s server folder)

   Meteor.methods({
        'insertJobLocation': function(username, jobLoc) {
            JobLocations.insert({
                jl_username: username,
                jl_jobloc: jobLoc,
                jl_created_by: Meteor.userId()
            });
        },

Stepping through the code in CDT, I see that the “if (err)” block equates to true, and the error message is “Internal Server Error [500]”:

I know that “500” is a pretty common and general err msg, but what in my code could be causing this?

2

The most likely cause of this is that you have your JobLocations collection defined only on the client.

3

You can see the real error message (on the server side) in the terminal window you’re running meteor from.

2 Likes
4

As @mjmasn said, have a look at your terminal where you’re running Meteor. Also use this.userId in a method instead of Meteor.userId()

2 Likes
5

It’s true that I only have my Collections defined in one place - in \lib\mongo.js

If I need to define it in two places, where would the second place be - in \server*.js?

And is it just a copy-and-paste operation?

If so, it seems rather unnecessary…I thought there was a location (such as the \lib\ folder) where both client and server code could be placed.

6

The lib folder is definitely a good place for having it in both client and server.

I suspect @fvg’s answer is the right one, but check your server’s console as @mjmasn says.

7

Thanks all, I will experiment with these suggestion when I get time (hopefully sometime tonight).

8

Well, 3 years later this still appears to be an issue. What I see at the client is the MiniMongo error that contains the message I need to determine what happened in client code. But that is immediately followed by an internal server error, which is the one actually returned to my code.

The server does see the correct message, but that does not help me put up a toast at the client.

Thoughts?

handleAdd(device) {
        device._id = device.serial;
        Devices.insert(device, err => {
            if (err) {
                console.log(err);
                toastr.error(`Error: failed to add device ${device.model} -- ${device.serial} : ${err.message}`);
                return;
            } else {
                this.state.device = device;
                this.state = {...device};
                this.props.toggle();
                toastr.info(`device ${device.serial} added`);
            }
        });
    }
1 Like
9

Well, as far as I can tell, an insert error cannot be issued in MiniMongo simply because it operates on subsets of the data, so it must make the round trip to the server to attempt it there.

The internal server error appears to come from there being no code in MiniMongo to hoist obvious errors like “_id already exists” on an insert command. This should come back as a Mongo error with that code or text available for parsing.

Presumably, to get proper error messages we are forced to make the round trip ourselves with a method call, which I consider massive overhead that is unnecessary. It is a surprisingly unfinished area so late in Meteor’s history. But I suppose it is at least solvable if you don’t mind writing unnecessary code.

10

It’s not really “unfinished”, it’s an unusual case - if you are using Random.id() the likelihood of a conflict is extremely small, if you are generating your own ID’s it’s your responsibility to ensure they are unique - there are other edge cases where you get this error, for example non _id unique keys. In general, any verification done on the server can also be done on the client (schema, security, etc) so you can avoid this problem. The reason the server returns a 500 error is to avoid leaking errors to the client that are not explicitly created. Without this it’s possible for the server to throw an error “Mongo connection to mongodb://admin:password@mysecrethost.com failed” - so in general it’s a good thing!