* feat: add VerificationAttempt model to verify_student application
This commits adds a VerificationAttempt model to store implementation and provider agnostic information about identity verification attempts in the platform.
* feat: add api for VerificationAttempt model
* fix: error handling for update
- added tests accordingly
- also took care of some nits
* chore: lint
* chore: lint for equals spaces
* feat: using generic update function instead
- can now update name, status, and exp. date on generic attempts
- changed tests accordingly
- a few nits
* chore: fix docstring args
* fix: corrected status validation
- reverted to old status validation method
- fixed tests accordingly
* fix: datetime, status, and annotation fixes
- expiration_datetime can be updated to None
- VerificationAttemptStatus is now StrEnum
- Added type annotations for api functions
---------
Co-authored-by: michaelroytman <mroytman@edx.org>
This commits adds a VerificationAttempt model to store implementation and provider agnostic information about identity verification attempts in the platform.
* feat: save author pronoun separately for notification to prevent info loss
* fix: missing pronoun in comment on followed post
* test: updated tests for new comment notifications
We sometimes see rendering errors in the error page itself, which then
cause another attempt at rendering the error page. I'm not sure _exactly_
how the loop is occurring, but it looks something like this:
1. An error is raised in a view or middleware and is not caught by
application code
2. Django catches the error and calls the registered uncaught error
handler
3. Our handler tries to render an error page
4. The rendering code raises an error
5. GOTO 2 (until some sort of server limit is reached)
By catching all errors raised during error-page render and substituting in
a hardcoded string, we can reduce server resources, avoid logging massive
sequences of recursive stack traces, and still give the user *some*
indication that yes, there was a problem.
This should help address https://github.com/openedx/edx-platform/issues/35151
At least one of these rendering errors is known to be due to a translation
error. There's a separate issue for restoring translation quality so that
we avoid those issues in the future (https://github.com/openedx/openedx-translations/issues/549)
but in general we should catch all rendering errors, including unknown
ones.
Testing:
- In `lms/envs/devstack.py` change `DEBUG` to `False` to ensure that the
usual error page is displayed (rather than the debug error page).
- Add line `1/0` to the top of the `student_dashboard` function in
`common/djangoapps/student/views/dashboard.py` to make that view error.
- In `lms/templates/static_templates/server-error.html` replace
`static.get_platform_name()` with `None * 7` to make the error template
itself produce an error.
- Visit <http://localhost:18000/dashboard>.
Without the fix, the response takes 10 seconds and produces a 6 MB, 85k
line set of stack traces and the page displays "A server error occurred.
Please contact the administrator."
With the fix, the response takes less than a second and produces three
stack traces (one of which contains the error page's rendering error).
