Dispatch network fail actions for more failed fetches. #824
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Closes #775. Until now, we only dispatched `..._NETWORK_FAIL` actions when a fetch failed and the browser deemed it a network error of a certain kind, per the `message` property of the thrown error. However, we shouldn't assume that all browsers will set the error's `message` property in the same way, and we should recover robustly when we are unable to parse JSON from the response body (e.g. due to an error at the level of a reverse proxy server). By being too picky about what the thrown error looked like, we were failing to clean up after certain kinds of non-HTTP/network error, which was usually asymptomatic, but in the case of ballot manifest and CVR export uploads, could lead to a "stuck" spinner state. These changes fix that.
dmzimmerman
approved these changes
Oct 9, 2017
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #775.
Until now, we only dispatched
..._NETWORK_FAILactions when afetchfailed and the browser deemed it a network error of a certain kind,
per the
messageproperty of the thrown error. However, we shouldn'tassume that all browsers will set the error's
messageproperty inthe same way, and we should recover robustly when we are unable to
parse JSON from the response body (e.g. due to an error at the level
of a reverse proxy server).
By being too picky about what the thrown error looked like, we were
failing to clean up after certain kinds of non-HTTP/network error,
which was usually asymptomatic, but in the case of ballot manifest and
CVR export uploads, could lead to a "stuck" spinner state. These
changes fix that.