Collection hooks success / error

[geekyme]

Hey there,

I was just experimenting with this package and I tried something like...

Posts.after.insert(function(userId, doc){
  console.log(doc);
});

It appears that the hook is still called even if my Posts insert failed (due to allow / deny rules). Is there a way to only run the hooks on insert success? Or optionally run something else if there is an error?

[mizzao]

That's a good point. I'm guessing there are other cases where the hook may fail as well on the server, but this will throw an error and cancel the whole process as it runs synchronously.

Does the client hook run after the simulation or after the server method has returned? I imagine it's the former, in which case there is no way to know that the operation will cause an error. It doesn't really make sense to wait for the asynchronous callback in order to run the hook, unfortunately.

Maybe you should just try to do this in a method instead?

[matb33]

Hmm it's not supposed to be called if allow/deny prevent the insert. Can you verify that you don't have the insecure package enabled?

[mizzao]

@matb33 I don't see how you can know that the insert was prevented on the client because the operation returns asynchronously, unless the hooks also run asynchronously on the client (I didn't think they did?)

[geekyme]

yeah I do not have the insecure package enabled.

Well, I could somehow (i think) run the hooks only if the operations succeed by placing the hooks in the /server/ folder.

But then the above would only work if all my Posts.inserts are triggered on the client side. I'm curious if somehow Posts.insert got run on the server side, and it failed, will the hook will still run?

[mizzao]

If you are defining the hooks in a server/client folder, you will need to be careful as they will run on both sides. In particular I think the client one will run with the simulation, and the server one will run with the canonical operation. The write fence and latency compensation should work as normal, so any operation the client hook does should be rewound if the server operation fails.

[matb33]

@mizzao you're correct -- forgot about the client version. Having your hooks run only on the server will work as intended. You can call insert etc from the client or server and the server-defined hook will only run if the collection validators succeed.

Using a hook on the client is only really useful for latency compensation work, i.e. changing/adding some properties on the document -- not for triggering actions. Those are best defined in server hooks where the validation has a chance to run.

[matb33]

With regards to my comment above, in most typical use cases, you would declare a hook that runs on both server and client in order to add/modify properties (like createdAt for example).

For hooks that do more serious work, for example deleting a related document in another collection, those hooks would be declared on the server only, where validators have had a chance to run.

[geekyme]

@mizzao when you say server/client, do you mean server OR client? Or do you mean the folder server/client will run on both sides?

@matb33 when i define my hooks only in /server/, they run correctly in the server only.

[matb33]

server/ will run on server only client/ will run on client only

anything else runs in both server and client (which is where you'd declare hooks that mutate your document for latency compensation reasons)

[geekyme]

PHEW. ok for a while I thought I got it all wrong in meteor. So ok for this issue, if we trigger operations from client side, and define hooks on the server side, we can be sure that the hooks only run when the operations succeed yes?

Now what if I want to do something else when the operation failed?

[matb33]

You would normally do this in the async callback where you get an error object and run your logic there. Or you could do it in the allow/deny functions themselves but that would get dirty pretty fast.

[geekyme]

yeah but in the allow/deny functions, I cant do ....

Posts.allow({
 update: function(){
      throw new Meteor.Error(400, 'error');
 }
}); 
Posts.allow({
 update: function(){
      return true;
 }
}); 

.... and then expect my Post to succeed? I realized when I do the above, I get the error message but the throw Error seems to make Meteor skip the rest of the allow callbacks (which could return true)

[mizzao]

@geekyme you are not supposed to throw errors in allow/deny hooks: http://docs.meteor.com/#allow ; return true or false only. If the operation is not allowed, Meteor will throw the error for you.

Regarding server/client I was talking about places where code would run on both.