Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Spinner doesn't go away until you log off for 33K or more CVRs (in Chrome) #775

Open
sfsinger19103 opened this issue Sep 26, 2017 · 6 comments · Fixed by #824
Open

Spinner doesn't go away until you log off for 33K or more CVRs (in Chrome) #775

sfsinger19103 opened this issue Sep 26, 2017 · 6 comments · Fixed by #824
Assignees
@ranweiler
Labels
bug CDOS Request
Milestone
fourth and final ...

Comments

@sfsinger19103
Copy link
Contributor

Verbal description from CDOS: at 33K CVRs the spinner doesn’t go away until you log off, or until the state starts the audit.

[We expect to receive a more carefully documented description, with screenshots, by the end of the week.]
@sfsinger19103
Copy link
Contributor Author

See Test Case #5, in https://drive.google.com/open?id=0B5_BzTbq3XxPYUVhVnNSaEZQOGs

@ranweiler
Copy link
Contributor

@sfsinger19103, I can't reproduce this locally. I think the problem is just that it is taking a long time to process the CVR export file, and the users are not getting progress indication other than the spinner. Regardless, this isn't a client bug, unless we can reproduce a case where (1) the CVR export upload_and_ import succeeded per the server logs, but (2) the client is still stuck in a spinner state.

@ranweiler
Copy link
Contributor

Note: I tested the case where I manually interrupt the backend import processing, causing a network failure. As expected, the spinner disappears, the CVR export form resets to its initial state, and the user gets an error message.

@ranweiler
Copy link
Contributor

Closing unless someone can repro.

@ranweiler
Copy link
Contributor

CDOS is still observing this bug in their environment. Reopening while we help identify a repro and fix.

@ranweiler ranweiler reopened this Oct 9, 2017
ranweiler added a commit that referenced this issue Oct 9, 2017
@ranweiler
Dispatch network fail actions for more failed fetches.
1c09e18 
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.
@ranweiler ranweiler mentioned this issue Oct 9, 2017
Merged
@ranweiler
Copy link
Contributor

This was auto-closed; reopening until we confirm that this is fixed for CDOS.

@ranweiler ranweiler reopened this Oct 9, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@ranweiler ranweiler

Labels
bug CDOS Request
Projects
None yet
Milestone
fourth and final release
Development

Successfully merging a pull request may close this issue.

Dispatch network fail actions for more failed fetches. FreeAndFair/ColoradoRLA
2 participants
@ranweiler @sfsinger19103