2017-06-17 1 views
4

Ich habe ein Angular SPA Ich laufe mit Angular Loading Bar und AngularJS v1.4.9.Stuck mit endlos wiederholenden Digest Loops

Seit einiger Zeit ist es so, dass nach dem Laden der App die Leiste nach einiger Zeit hängen bleibt und anzeigt, dass nicht alle Anfragen erledigt sind. Zusätzlich hat einer der console.log() s, die ich in unserem Code habe, ununterbrochen, ungefähr 1-2 mal jede Sekunde, geschossen. Die Leiste wird abgeschlossen, und die Datei console.log funktioniert normal, wenn der Benutzer die Seite neu lädt (aber nicht von selbst beendet).

Die console.log() ist in eine Funktion, die an eine ng-disabled Direktive angeschlossen ist, gesetzt, also weiß ich, dass es ein Indikator für einen Digest-Zyklus in Arbeit ist.

Ich benutze Chrome als meinen Browser und ich habe kürzlich einen Profiling-Lauf gemacht. Hier einige Screenshots von dem, was ich sehe: Bird's eye view

Dies ist eine breite Sicht ist. Wie hier gezeigt, passiert es zuerst bei 100ms, dann bei 400, dann bei 600 und so weiter (ich habe einen 3s Lauf gemacht).

strip 1 Dies ist der allererste vertikale Streifen. Nicht alle von ihnen sehen genau so aus, aber die Methoden completeOutstandingRequest, timeout und Browser.self.defer sind immer da. Die Methoden searchDisable und log sind unsere, das Protokoll ist das, über das ich oben gesprochen habe. self.url Hier ist ein anderer zum Vergleich, aber das ist etwas anders - es hat eine andere Browser-Methode: self.url. Ich bin mir nicht sicher, was es tut.

Hier sind einige Fragen, die ich gefunden, die zusammenhängen könnte:

Timeout callback can occur in the middle of a digest cycle in Firefox
$browser.defer ends up triggering changeDetection in zonejs through settimeout

P. S. Ich denke, dass dieses Problem zuerst begann, als wir unserem Code einige Interzeptoren hinzufügten, um einige automatische Weiterleitungen vorzunehmen - z. Wenn die Sitzung abgelaufen ist und der Benutzer auf etwas klickt, kehrt er automatisch zur Anmeldeseite zurück, um sich erneut anzumelden.

Dies ist der Interceptor:

 interceptor.$inject = ['$rootScope', '$q']; 
     function interceptor($rootScope, $q) { 
      return { 
       responseError: function (rejection) { 
        var config = rejection.config || {}; 
        if (!config.ignoreAuthModule) { 
         switch (rejection.status) { 
          case 401: 
           var deferred = $q.defer(); 
           $rootScope.$broadcast('event:auth-loginRequired', rejection); 
           return deferred.promise; 
          case 403: 
           $rootScope.$broadcast('event:auth-forbidden', rejection); 
           break; 
         } 
        } 
        return $q.reject(rejection); 
       } 
      }; 
     } 

     $httpProvider.interceptors.push(interceptor); 
+0

Hinweis für die Gemeinschaft: Ich finde es schwierig, eine Geige/PLNKR für diese Frage aufgrund ihrer Natur zu erstellen. Wenn es hilft, gibt es ein [Problem] (https://github.com/chieffancypants/angular-loading-bar/issues/360), das auf GitHub verlinkt ist, das hier zurückverbindet. Jede Eingabe ist willkommen. – cst1992

+0

ist 'rejection.status' in' 401' oder '403'? Wenn nicht .. kann die Anfrage niemals enden – Sravan

+0

@Sravan Weder. Es verursacht einen separaten Konflikt. Das Hinzufügen eines 'console.log' in den Interceptor gibt nichts aus. Vielmehr findet der Überfall tiefer im Verdauungszyklus statt. – cst1992

Antwort

0

Dieses Problem wurde gelöst.

Es stellt sich heraus, dass im Fall von Unauthorized Anfragen, das Versprechen, dass auf der Leitung zurückgeführt wird 11 oben verbleibenden immer anhängig war, weil es kein Aufruf .resolve() oder .reject() im Objekt deferred war.

Als Ergebnis wurde der Interceptor des Ladebalkens blockiert.

Ich endete das benutzerdefinierte Versprechen vollständig zu entfernen und das Problem gelöst.