TypeError: Cannot read property 'config' of undefined when request is aborted

[lukasz-karolewski]

when http request is aborted response.config is undefined and ignoreLoadingBar is accessed without checking if response.config is not null in request, response and responseError handlers

'response': function(response) {
if (!response.config.ignoreLoadingBar && !isCached(response.config)) {

[TheCodeDestroyer]

I have the same issue...

[ghost]

I have the same problem if the request is aborted for example if the server returns a ERROR 500/ Status Code:500 Internal Server Error

Then the:
'response': function(response) {

response is undefined and the loading bar is stuck near the end of loading. You can easily simulate it with making a $http request to a service that responds with error 500

 TypeError: Cannot read property 'config' of undefined
    at interceptor.response (loading-bar.min.js:116)
    at processQueue (angular.js:13075)
    at angular.js:13091
    at Scope.$get.Scope.$eval (angular.js:14291)
    at Scope.$get.Scope.$digest (angular.js:14107)
    at Scope.$get.Scope.$apply (angular.js:14395)
    at done (angular.js:9569)
    at completeRequest (angular.js:9756)
    at XMLHttpRequest.requestLoaded (angular.js:9697)

the quick and ugly fix for it would be to change response to:

                    'response': function(response) {
                        if (!response) {
                            setComplete();
                            return;
                        }

The best would be maybe to change the color of the bar to red or something for a few seconds but that is the decision of the project owner

[bitliner]

Same here.
My response returns a 401 code. If fails on same line (because response is undefined).

It would be a problem, apart the fact that it blocks protractor e2e testing, because it looks like protractor keeps waiting for angular to finish, but it will never finish

[bitliner]

In my case, the problem looks coming from an other interceptor (in the appe there are 2 interceptors).
If I remove the first one, then there is no this issue anymore.

The problem was that an interceptor was not returning a promise if a condition has been verified

[JeanMeche]

Same issue here : I have another interceptor that cancels some resquests
FYI :

 'request': function(config) {
                    canceller.reject(config);
                    return canceller.promise;
}

My fix for loading-bar.js would be :

'response': function(response) {
if (! response.config) {
              $timeout(function(){setComplete()},1000);
} else if() ..... 



'responseError': function(rejection) {
if (! rejection.config) {
              $timeout(function(){setComplete()},1000);
}  else if() ..... 

the timeout allows the loading bar to appear and load which doesn't happen without it because of the sync call.

Would you consider a PR for this ?

[lord2800]

See: #50. You have a misconfigured interceptor.

[chieffancypants]

Yep-- sorry for the delay on this. Been really busy on a big project at work.

@lord2800 is correct. I'll push the new release today that has a check for this

[bhaveshvyas007]

This is not yet resolved? I am still getting error on latest version of this lib and Angular 1.6.2

[maciej-gurban]

@chieffancypants How I understand the docs, it's allowed to return a promise or a promise rejection from both request and reject interceptors. Here's the excerpt from Interceptors section:

request: interceptors get called with a http config object. The function is free to modify the config object or create a new one. The function needs to return the config object directly, or a promise containing the config or a new config object.
requestError: interceptor gets called when a previous interceptor threw an error or resolved with a rejection.

Unless I'm misunderstanding what previous interceptor means in this context, it seems valid to return a rejected promise inside a response interceptor, but angular-loading-bar will throw in such case.

Here's a fiddle demonstrating the problem.

The use case I have, is to prevent requests that would cause a 401 error due to being signed with an expired token. I verify the token on the client side, and the natural way for that check is to be in an interceptor, which works unless I add angular-loading-bar. I'm doing exactly what's in the fiddle: returning a rejected promise in request.