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.

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

Re-resolving issues leads to spinning UI state, 404 in backend #867

Open
ssciolla opened this issue Dec 1, 2022 · 0 comments · May be fixed by #873
Open

Re-resolving issues leads to spinning UI state, 404 in backend #867

ssciolla opened this issue Dec 1, 2022 · 0 comments · May be fixed by #873
Labels

Comments

@ssciolla
Copy link
Contributor

ssciolla commented Dec 1, 2022

Expected behavior

Users are able to resolve and un-resolve issues repeatedly without issue. Furthermore, users will see an indication of errors in the UI.

Actual behavior

When users try to resolve an issue that was previously un-resolved, they see a loading indicator that goes on perpetually. An inspection of the Web console shows two errors:

POST https://{app_url}/udoit3/api/issues/{issue id}/resolve 404
Uncaught (in promise) SyntaxError: Unexpected token '<', "<!DOCTYPE "... is not valid JSON

Steps to reproduce

  1. Once UDOIT is loaded in a course, open an issue in the modal.
  2. Check the resolve checkbox; wait for the action to occur.
  3. Uncheck the resolve checkbox; wait for the action to occur.
  4. Check the resolve checkbox again; observe that the action never completes.

Commentary

This problem appears to be because un-resolving an issue leads to a new issue being created (with a different ID) rather than an update to the existing issue. There might be a way to resolve this through significant refactoring in the backend, but the frontend could also be modified so that the former issue is replaced with the new issue, or at least an unresolved one. Regarding the lack of an error message, I'm not sure if there's an existing mechanism for reporting an HTTP error, or if there was some design choice related to this. The React application could probably benefit from a consistent error handling strategy if not.

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

Successfully merging a pull request may close this issue.

2 participants