requireUser sometimes hangs

[mxab]

Hi,

we experience some resolving/rejecting issue in our application. we call requireUser but the then handlers are never called.

I started todo some logging in the metoer-angular-auth but it looks ok

it autoruns, finds a valid user, enqueues the deferred.resolve int the $$afterFlush, the Tracker.afterFlush gets also called, but then it disappears.

any ideas what the problem might be?

[DAB0mB]

@mxab I tried to test this issue and it all seems fine for me. I tested it using angular-meteor-whatsapp project, I used requireUser instead of awaitUser before resolving the routes (see referene), and I even tried to fulfill the promise in ChatsCtrl initialization (see reference) and it worked properly as expected. I used meteor@1.3.0, angular-meteor@1.3.9 and angular-meteor-auth@1.0.2. Are you sure you didn't miss anything? Please provide me an example so I can analyze your issue.

[mxab]

it is really hard to reproduce it as we experience it randomly. I will try to replace it with awaitUser. Out of curiosity, the afterFlush seems very intentional in the requireUser part. I assume I should also do a Tracker.afterFlush then?

[DAB0mB]

The afterFlush() is there so the promise would be fulfilled once the current computation is finished, otherwise subscriptions made in the promise would be stopped. There is no need to call afterFlush(), just use the API as is.

[mxab]

Hmm I swtiched everything to await, but sill I have this random not finishing issue.

This is the peace of code that currently is the problem
In my $stateProvider.state({..}) definition:

 resolve: {
  'currentUser': function ($auth, $log, $timeout) {
    const awaitUser = $auth.awaitUser();
    $log.debug("awaitUser in AUTH");
    awaitUser.finally(()=> {
      $log.debug('DONE AWAITING USER');
    });
    return awaitUser;
   }
}

Quite often but so far random I see
awaitUser in AUTH
but not
DONE AWAITING USER

which does not make any sense to me

[DAB0mB]

Hmm I can't seem to reproduce your problem, everything works fine for me. Make sure you actually login before invoking awaitUser.

[dohomi]

@DAB0mB I'm working on the same project with @mxab

The problem occurs explicitly inside of the resolve of a $stateProvider.state() setup of ui-router

Following code does not work and accidentally fails for no reason - the .finally()of awaitUser will never getting called:

$stateProvider.state('auth', {
            url: '',
            abstract: true,
            resolve: {
                'currentUser': function($auth) {
                    return $auth.awaitUser();
                }
            }
        })

I replaced now the $auth.awaitUser() with standard Meteor code and it works. I am pretty sure that the reason belongs in the context of the resolve handler. Inside of a controller the code works without any issues.

        $stateProvider.state('auth', {
            url: '',
            abstract: true,
            resolve: {
                'currentUser': function($q) {
                    var defer = $q.defer();
                    Meteor.autorun(c => {
                        let loggingIn = Meteor.loggingIn();
                        if (!loggingIn) {
                            if (Meteor.userId()) {
                                defer.resolve();
                            } else {
                                defer.reject();
                            }
                            c.stop();
                        }
                    });
                    return defer.promise;
                }
            }
        })

I suspect the this.autorunwhich seems to work fine inside of any controller context - but fails if there is no controller context. Hope this helps to get closer to solve this issue

[dohomi]

I made a very small change inside of angular-meteor-auth.js in line 118:
I changed:

        var computation = this.autorun(function (computation) {

to

        var computation = Meteor.autorun(function (computation) {

And now the resolve handler works as expected. I'm getting the feeling that this.autorun, this.subscribe is only working in controller context and not inside of any other context.

[dohomi]

One important thing how to actually trigger this error, because most of the time on page reloads it works:
Open the link with the resolve handler with CMD+clickand open multiple times the link in new browser window. Then the resolve handler starting to stuck

[DAB0mB]

@dohomi you mentioned something about subscriptions. We actually had a similar issue which was already fixed, #8. Sadly I can't reproduce this problem so I wish I could help you but I can't, I used awaitUser in many of my projects and I never encountered any problems using it (unless you use older version of angular-meteor or angular-meteor-auth). If you can provide a repo which reproduces the problem I would be glad to help you. If you manage to find the source of the problem and a solution to it please share it with us so we can all enjoy it.

[DAB0mB]

Maybe there is some sort of a synchronous error thrown in the resolve handler and angular silently ignores it.

[dohomi]

I opened this issue where I had to switch back to Meteor.subscribe:
Urigo/angular-meteor#1338

[dohomi]

Is there anything against changing this.autorun to Tracker.autorun? For us it would solve the issue for now.

[DAB0mB]

@dohomi @mxab I'm having troubles reproducing the issue. If we can may a call or something it would be much easier and we can go through it together. Feel free to contact me on the email address presented in my Github account and I would be more than happy to listen and try to help you :-)

edit:
@dohomi for your recent comment there shouldn't be a problem, the main advantage of using $scope.subscribe() is that it will be stopped once the $scope has been destroyed.

[mxab]

Sounds good, we are currently trying to isolate the issue without luck, I want to make some more tests. I first got the feeling that the defer.resolve(user) somehow does not trigger the then but currently it looks more like that the autorun is not that reactive on the logginIn() call as it should.