-
Notifications
You must be signed in to change notification settings - Fork 27.4k
$http turns timeout into success using 'then' instead of failure via 'reject' #7686
Comments
Hmm, it's not clear why we're doing this, when XHR's timeout attribute should be more than enough --- for unit tests benefit I guess |
Oh, I see what's going on --- we're using readyState instead of proper event handling for XHR. This is really a bug, we should fix this, or at least also handle the abort event. |
An interim solution (for me at least). Is to add an httpInterceptor which takes the lack of status code and data and turns it into a 503. That seems to be resulting in a rejection at a higher level. |
Well, I'll try to get that merged tomorrow, SGTY? |
SGTY == Sounds Good To You ;) |
Sounds great! Thanks for the extremely rapid response guys. |
@bramski so Igor basically demonstrated that we are actually rejecting the promise (by default), I think we'd need to see what's going on if it's not working for you. And clearly I should have tried to reproduce it before writing a patch! But, we did get a new test added to the tree from it, so it's all good. If you can provide more info on your actual issue (because I don't doubt you're having a real issue), please open a new issue about it with a reproduction |
Was trying to figure out how to implement proper timeout handling today using 1.3.0-beta
However, it appears that when a timeout occurs $http treats this as a success instead of a rejection. This makes it very difficult to code against as it forces developers to write their lowest level request handling to intercept the promise success and redirect it into failure if the request is in fact a timeout.
https://stackoverflow.com/questions/21915834/angular-http-setting-a-promise-on-the-timeout-config/21916315#21916315?newreg=15bf947982404ed19f6e04b95c8ad068
The text was updated successfully, but these errors were encountered: