0

I flipped over to back4app, running Parse, and so far looooove it. I am working on a simple bit of cloudcode the seems to fight me at every step.

This idea: send up a channel string, do a simple find via Parse.Installation, and return a field in the first found record. Works like a charm WHEN the channel is found.

The issue: it takes over 60 seconds to return if no record is found. Return time for a found record is usually a split-second. I am not a javascript guru, and have tried numerous variants to no avail, and JSLint seems to not want to test out a Parse.Cloudcode.Define block.

The question: how structurally messed up am i here to cause this kind of delay? I am simply not seeing the issue. Any thoughts are most welcome:

Parse.Cloud.define("test", function(request, response) {

               var query = new Parse.Query(Parse.Installation);
               query.equalTo("channels", request.params.other);
               query.descending("updatedAt");
               query.first({
                           useMasterKey: true,
                           success: function(installation) {
                           response.success(installation.get("lastLoginAt"));
                           },
                           error: function(error) {
                           response.error("test");
                           }
                           });
               });

{edited function for useMasterKey: true ... no changes seen with timing issue}

drew..
  • 3,234
  • 3
  • 16
  • 19
  • The only thing that comes to mind is that you might need to index 'channels' in your mongodb. Secondly, just to mention it, the use of masterkey is discouraged, instead add `{ useMasterKey: true }` as the first argument to the query. – cYrixmorten Mar 07 '17 at 18:32
  • I don't have that level of control as back4app manages the Parse installation at their end. I have to assume that because [channels] is the key to proper push notifications, the indexing is in place. I will adjust the code and run that, as a just-in-case measure. Chatting with b4a, they suggested it *might* be the structure of the error block, but i have tried numerous styles to no avail. thx! – drew.. Mar 07 '17 at 22:19

1 Answers1

1

Not seeing any obvious issues, I'll just leave a snippet of how I would write it:

Parse.Cloud.define("test", function(request, response) {
    var query = new Parse.Query(Parse.Installation);
    query.equalTo("channels", request.params.other);
    query.descending("updatedAt");
    query.first({useMasterKey: true})
        .then(function(installation) {
            if (installation) {
                response.success(installation.get("lastLoginAt"));
            } else {
                response.error("No installation with channel: " + request.params.other);
            }
        })
});
Jason Braucht
  • 2,358
  • 19
  • 31
cYrixmorten
  • 7,110
  • 3
  • 25
  • 33
  • cYrix: you are golden. This works, and i have no explanation as to why mine original code won't. The 60sec delay is seemingly a deep bug somewhere. I originally had the .then structure but NOT the .fail block. This did the trick and will hopefully help unstop others. THANK YOU. – drew.. Mar 08 '17 at 17:33
  • My bad, i was assuming the good block would work and only tested the block that results in no record found. The code above results in a 141 for both cases, which indicates something amiss in the code itself. I don't see it as yet, sigh. Apparently i suck with javascript ;) I even ripped out everything to have one simple return block. That takes over 60sec to return with an error of "No Value". Something is amiss.. Perhaps this is a back4app issue? – drew.. Mar 08 '17 at 18:18
  • Hmm bummer. I have no experience with back4app. Switched to heroku + mlabs when Parse.com was shut down – cYrixmorten Mar 08 '17 at 18:30
  • I pinged them with this url, hopefully they have a chance to resolve this. – drew.. Mar 09 '17 at 01:17
  • 141 sounds to me as the cloud function was not found? Also, just realised that the `first` query on android always returns a positive result. That is, not throwing error on no results. Updated the code (in case the javascript SDK behaves in the same manner) – cYrixmorten Mar 09 '17 at 13:27
  • In this case, it is found, as i have a testing routine that alternately sends over a findable string and then the unfindable string. The first call works, the second results in the extended return time. One friend suggested it is a mongoldb issue wherein a very extended set of records is being scanned as opposed to the limited subset of records i "own". I am hoping b4a can test this soon. – drew.. Mar 09 '17 at 16:44
  • cYrix: you are NOW golden. That did it, and it returns in all cases in my tests. There is clearly something amiss in how mongoldb is managing this (or how the javascript is handling the latency). Regardless, my code is returning in an instant for both lost and found. THANK YOU. There was an extra set of closing brackets in the last example, I will edit them out. – drew.. Mar 09 '17 at 17:03
  • I'm happy to hear that it worked! :D You are absolutely welcome. Remember I had a similar problem on Android where I assumed an `OBJECT_NOT_FOUND` error or the like would be thrown when the result is empty. – cYrixmorten Mar 10 '17 at 07:42