I’m a new member here, and relatively new to metoer, but still already got a lot of help from these forums, thank you all for that!
For the last few days I’m struggling with a problem, and couldn’t find a full solution to it:
The short version - is there a way to prevent Meteor.aplly(), when using “noRetry”, from sending error massage, and just keep the former “original” call to the method alive even after disconnecting and reconnecting?
The long version: We develop an app which will be used mainly in ereas where internet connection is not very stable. One of our methods runs a very heavy process, which can take up to 3 minutes(!) to complete sometimes, and combinig it with unstable connection can cause trouble. At first I called this method with Meteor.call(), but when disconnecting and reconnecting on the time the mothod runs the process, Meteor.call() fires the call again (because it didn’t get the response), and that makes a big mess, Quentin Tarantino’s kind of a mess. So I’ve tryed Meteor.aplly() with “noRetry” option. This indeed prevented the recall, but a new problem showed: instead of resend the call, it sends error message, and the client ignored the results when the server finished the process.
I checked again in meteor documentation for “noRetry”, and it’s actually written there: "if true, don’t send this method again on reload, simply call the callback an error with the error code ‘invocation-failed’."
I hope the short version makes sence now…
Making a unique “call ID” and have the server check it before executing the method solved only part of the problems (and created some new ones) so a different solution is preferred.
Instead of having the method return data directly, have it write to a collection (use your unique call id as the _id). Then the retry (in a normal call/apply) can just check the _id. If it’s in the collection, it returns the data. If not it starts work, but returns straight away.
Agree, I think he should create a method which creates a job run on the server and immediately return a status of the job, e.g running.
On the client side, he subscriber the job collection then update/do something when the status updated.
It will have better UX.
Thanks. I am already using a collection, but now the server (method) writes to it and the client reads from it. I’ll try to do it your way - instead of read and write have the method return the results directly (until now I prefered to avoid this way here because there are 2 “results” to the method and I wanted the client to access them without them depend on each other) and use the collection for checking. thanks for that!
I’m not sure I understand what the status gives me, where should I check it.
right now I’m using a tracker to follow changes in the collection (I’m using react)
On second thought, this won’t help, because if the client reconnects before the method finished the process, the db will not have the result yet, retry will happen, and we’re back to square 1. Or am I missing something here?