Throw error if cursor is returned from a method

[peonmodel]

_1 Upvote_ repro here: https://github.com/peonmodel/adamant-waffle

basically is a server side meteor method is returning a cursor, the client side callback will not get called at all

    Meteor.methods({
            'test': function(obj){
                obj.fakefield += 1;
                delete obj._id;
                var id = TestCollection.insert(obj);
                var insert = TestCollection.find(id);  // <<< this line!
                return insert;
            }
        });

Meteor.call('test', previous, function(error, result){
                console.log('callback')  // will not get called
                if (error){
                    console.log(error)  // nor here
                } else {
                    console.log(result)  // nor here
                }
            })

it doesnt quite make sense to return a cursor from a method, but it is an easy mistake to make mistyping 'findOne' as 'find'
i would expect the error callback to get triggered instead of failing silently

[peonmodel]

no, in the example i have posted, i didn't receive any error on the server,
i had just double checked, it fails silently on both client and server side

On Thu, Oct 8, 2015 at 11:02 AM, Sashko Stubailo notifications@github.com
wrote:

Is there any error on the server?

—
Reply to this email directly or view it on GitHub
#5382 (comment).

[jsbranco]

+1 Same here.. findOne() returns triggers the callback but returning a cursor ( using find() ) there is no callback triggered.

The below are the scenarios I have tested:

//Doesn't trigger a callback
Meteor.methods({
   "retrievePageEvents": function (pageid) {
        return FacebookEvent.find({page: pageid});
    }
});

//Triggers callback
Meteor.methods({
   "retrievePageEvents": function (pageid) {
        return FacebookEvent.find({page: pageid}).fetch()
    }
});
//Triggers callback
Meteor.methods({
   "retrievePageEvents": function (pageid) {
        return FacebookEvent.findOne({page: pageid})
    }
});

EDIT : Also tested to just fire the "find" on the client side and it works fine.

//Returning cursor to template and handled correctly.
Template.activeFbEvents.helpers({
    pageEvents: function (routeData) {
        if (routeData) {

            return  FacebookEvent.find({page: routeData.pageid});;

        }

    }

I feel strongly that there might be an issue triggering the callback from a meteor method.

@peonmodel did you manage to resolve this issue?

[peonmodel]

No, i did not, still awaiting a reply from the meteor team
I just take note to not return the cursor from a meteor method

[jsbranco]

@peonmodel right.. I went for the same approach, if I need to return a cursor, I will do it in the helper itself.

Hopefully this gets fixed soon. I tried to find the source code for the method call but so far haven't found it

[stubailo]

Yeah, returning a cursor from a method should throw an error, since cursors are not serializable.

[zol]

Can someone confirm that returning anything that is non-serializable results in a silent error?

[zol]

@peonmodel I can't access your repro

[peonmodel]

@zol i created a new repo: https://github.com/peonmodel/musical-journey

on client-side

Template.hello.events({
  'click button.obj'(event, instance) {
    Meteor.call('returnObject', (err, res)=>{
            console.log(err, res);  // gets called, get {name: 'Test'}
        });
  },
    'click button.cur'(event, instance) {
    Meteor.call('returnCursor', (err, res)=>{
            console.log(err, res);  // nothing <<<
        });
  },
    'click button.err'(event, instance) {
    Meteor.call('returnError', (err, res)=>{
            console.log(err, res);  // gets meteor error 'Test'
        });
  },
});

on server-side

Meteor.methods({
    'returnObject': function(){
        return TestCollection.findOne({name: 'Test'});
    },
    'returnCursor': function(){
        return TestCollection.find({name: 'Test'});
    },
    'returnError': function(){
        throw new Meteor.Error('error');
    },
});

[zol]

Thanks!

[zbyte64]

Still an issue with meteor 1.4.2.1

[hwillson]

To help provide a more clear separation between feature requests and bugs, and to help clean up the feature request backlog, Meteor feature requests are now being managed under the https://github.com/meteor/meteor-feature-requests repository.

This feature request will be closed here, but anyone interested in migrating this feature request to the new repository (to make sure it stays active), can click here to start the feature request migration process. This manual migration process is intended to help identify which of the older feature requests are still considered to be of value to the community. Thanks!