Skip to content
This repository was archived by the owner on Apr 12, 2024. It is now read-only.

$http turns timeout into success using 'then' instead of failure via 'reject' #7686

Closed
bramski opened this issue Jun 4, 2014 · 7 comments
Closed

Comments

@bramski
Copy link

bramski commented Jun 4, 2014

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

@caitp
Copy link
Contributor

caitp commented Jun 4, 2014

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

@caitp
Copy link
Contributor

caitp commented Jun 4, 2014

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.

@bramski
Copy link
Author

bramski commented Jun 4, 2014

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.

@caitp
Copy link
Contributor

caitp commented Jun 4, 2014

Well, I'll try to get that merged tomorrow, SGTY?

@matsko
Copy link
Contributor

matsko commented Jun 4, 2014

SGTY == Sounds Good To You ;)

@bramski
Copy link
Author

bramski commented Jun 4, 2014

Sounds great! Thanks for the extremely rapid response guys.

@caitp
Copy link
Contributor

caitp commented Jun 6, 2014

@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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants