Fix integrity error handling by jesperhodge · Pull Request #536 · openedx/openedx-core

jesperhodge · 2026-04-08T22:01:57Z

Idea right now:

Validate against duplicate values before they reach the database and cause an IntegrityError (this is not implemented here yet)
Handle any uncaught internal errors, including integrity errors, throughout content-tagging. For security reasons we do not want to expose internal error information directly so we return a generic 500 response.
I made a custom error handling mixin so that this is handled for the content_tagging api in general.

Question: This would be better handled at the CMS level?

Answer: There is ongoing work to fix this up, starting with a proposal. See https://openedx.slack.com/archives/CHYH0BDTR/p1775053660743269 and openedx/openedx-platform#38246 in particular.

openedx-webhooks · 2026-04-08T22:02:05Z

Thanks for the pull request, @jesperhodge!

This repository is currently maintained by @axim-engineering.

Once you've gone through the following steps feel free to tag them in a comment and let them know that your changes are ready for engineering review.

🔘 Get product approval

If you haven't already, check this list to see if your contribution needs to go through the product review process.

If it does, you'll need to submit a product proposal for your contribution, and have it reviewed by the Product Working Group.
- This process (including the steps you'll need to take) is documented here.
If it doesn't, simply proceed with the next step.

🔘 Provide context

To help your reviewers and other members of the community understand the purpose and larger context of your changes, feel free to add as much of the following information to the PR description as you can:

Dependencies

This PR must be merged before / after / at the same time as ...
Blockers

This PR is waiting for OEP-1234 to be accepted.
Timeline information

This PR must be merged by XX date because ...
Partner information

This is for a course on edx.org.
Supporting documentation
Relevant Open edX discussion forum threads

🔘 Get a green build

If one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green.

Details

Where can I find more information?

If you'd like to get more details on all aspects of the review process for open source pull requests (OSPRs), check out the following resources:

When can I expect my changes to be merged?

Our goal is to get community contributions seen and reviewed as efficiently as possible.

However, the amount of time that it takes to review and merge a PR can vary significantly based on factors such as:

The size and impact of the changes that it introduces
The need for product review
Maintenance status of the parent repository

💡 As a result it may take up to several weeks or months to complete a review and merge your PR.

kdmccormick

@jesperhodge I agree that exception details should not be passed to the end user on a production site. However, it's useful behavior for developers. I'd expect the stack trace to be passed upwards when DEBUG==True, and a generic 500 to be shown when DEBUG==False.

Did you test with DEBUG==False? You can do django settings override, or just run the site with tutor local ....

kdmccormick · 2026-04-09T16:41:09Z

To you other point:

Validate against duplicate values before they reach the database and cause an IntegrityError (this is not implemented here yet)

yep, I agree. I think it's fine to either check for conflicts before renaming the tag, or use a very targeted except IntegrityError to catch the conflict.

jesperhodge · 2026-04-09T21:06:51Z

I did have a look at openedx/openedx-platform#38246, an ADR in review that aims to standardize errors platform-wide. (Also reviewed it and left my thoughts.)

I decided against implementing the proposed format more extensively here at this point, since there is still a lot to discuss around that.

Rather, I think it makes sense that after that ADR is finalized we just implement a top-level CMS error handler, and this temporary solution in this PR can be removed at that time.

kdmccormick · 2026-04-09T21:09:58Z

To close the loop on this:

Did you test with DEBUG==False? You can do django settings override, or just run the site with tutor local ....

Jesper discussed in Slack that he did test with DEBUG==False, and he and Braden confirmed that this error detail leakage is a standing issue with DRF in general.

Rather, I think it makes sense that after that ADR is finalized we just implement a top-level CMS error handler, and this temporary solution in this PR can be removed at that time.

That approach sounds good to me @jesperhodge . Could you just include a link to the ADR PR in the temporary handlers so that we remember to remove them later?

kdmccormick

Thanks for thinking this through and coming up with a stop-gap solution.

kdmccormick · 2026-04-09T23:11:43Z

@@ -4,12 +4,14 @@
 from __future__ import annotations


Thanks for the comprehensive tests.

kdmccormick

Just one last request, and then we're good to merge. Thanks!

kdmccormick · 2026-04-13T17:51:40Z

Squashing as:

fix(tagging): Handle rename conflicts; Better 500 handling

This fixes two issues: 
1. Renaming a tag such that it conflicts with an existing tag should result
   in a 4xx and a helpful error message. 
2. Unexpected errors while handling requests should result in a simple
   500 error response without internal details (unless in debug mode)
   and a log message with exception details. This is default Django behavior.
   However DRF returns internal exception details, which is confusing to
   users and bad security practice.  This PR restores the default Django behavior
   for the Tagging API in particular. In the future, we'd like to generalize this handler
   to work for all our DRF APIs.

Fixes: https://github.com/openedx/modular-learning/issues/261

kdmccormick · 2026-04-13T17:52:45Z

+        queryset = Tag.objects.filter(taxonomy_id=taxonomy_id, value=value)
+        if queryset.exists():
+            raise serializers.ValidationError(
+                f'Tag value "{value}" already exists in this taxonomy.', code='unique'


Sorry @jesperhodge , I only just thought of this after merging:

Do these validation strings appear in the end user UI? If so, they need to be internationalized.

Can you give me an example of how we do that?
As far as I see, we are not internationalizing a single error response in the whole repository.

I think since this is ubiquitous that would call for a new issue that has a bit wider scope and would include internationalizing other error messages like this. What do you think?

Is there any prior art in edx-platform?

Hmm I had a quick look at edx-platform.

It seems like that in edx-platform, ValidationError messages forwarded to the frontend on edx-platform are also not internationalized, for example https://github.com/openedx/openedx-platform/blob/77293cdf8e97eddcb3db32624b690dff8fe5d0df/lms/djangoapps/badges/models.py#L15

@jesperhodge

As far as I see, we are not internationalizing a single error response in the whole repository.

Ack, you're right, and it's worse than that--nothing in this repo is internationalized. And I guess we've noticed that before, too: #483 . No need for you to do anything here--we'll do a big sweep of internationalization at some point in the future. Thanks for checking on that.

would include internationalizing other error messages like this. What do you think?

I think the rule of thumb is "If the user will see it, it must be internationalized" rather than a blanket "all exceptions strings do/don't need to be internationalized".

Is there any prior art in edx-platform?

Yes, we use the standard gettext function for all translation. Usually we alias it to _:

from django.utils.translation import gettext as _ my_message = _("translate me") my_template = _("hello {name}, translate me")

It seems like that in edx-platform, ValidationError messages forwarded to the frontend on edx-platform are also not internationalized, for example https://github.com/openedx/openedx-platform/blob/77293cdf8e97eddcb3db32624b690dff8fe5d0df/lms/djangoapps/badges/models.py#L15

That message is internationalized. The _ function returns the localized string, if it available.

That message is internationalized. The _ function returns the localized string, if it available.

Oh! That's good

openedx-webhooks added the open-source-contribution PR author is not from Axim or 2U label Apr 8, 2026

openedx-webhooks added this to Contributions Apr 8, 2026

github-project-automation bot moved this to Needs Triage in Contributions Apr 8, 2026

kdmccormick requested changes Apr 9, 2026

View reviewed changes

mphilbrick211 moved this from Needs Triage to Waiting on Author in Contributions Apr 9, 2026

jesperhodge requested a review from kdmccormick April 9, 2026 22:08

jesperhodge marked this pull request as ready for review April 9, 2026 22:09

kdmccormick requested changes Apr 9, 2026

View reviewed changes

jesperhodge requested a review from kdmccormick April 13, 2026 16:06

jesperhodge force-pushed the fix-integrity-error branch 2 times, most recently from e0475c8 to 6e25f2d Compare April 13, 2026 16:10

kdmccormick reviewed Apr 13, 2026

View reviewed changes

Comment thread src/openedx_tagging/rest_api/v1/exception_handlers.py Outdated

jesperhodge added 2 commits April 13, 2026 13:26

fix: handle unexpected error and duplicates

ddc1ed7

fix: lint

790825a

jesperhodge force-pushed the fix-integrity-error branch from 290fda5 to 3dd0700 Compare April 13, 2026 17:26

fix: apply PR suggestion

d942235

jesperhodge force-pushed the fix-integrity-error branch from 3dd0700 to d942235 Compare April 13, 2026 17:28

jesperhodge requested a review from kdmccormick April 13, 2026 17:28

kdmccormick approved these changes Apr 13, 2026

View reviewed changes

kdmccormick merged commit 52bcdcf into openedx:main Apr 13, 2026
6 checks passed

github-project-automation bot moved this from Waiting on Author to Done in Contributions Apr 13, 2026

kdmccormick reviewed Apr 13, 2026

View reviewed changes

Conversation

jesperhodge commented Apr 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openedx-webhooks commented Apr 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kdmccormick left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kdmccormick commented Apr 9, 2026

Uh oh!

jesperhodge commented Apr 9, 2026

Uh oh!

kdmccormick commented Apr 9, 2026

Uh oh!

kdmccormick left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

kdmccormick Apr 9, 2026

Choose a reason for hiding this comment

Uh oh!

kdmccormick left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

kdmccormick commented Apr 13, 2026

Uh oh!

Uh oh!

kdmccormick Apr 13, 2026

Choose a reason for hiding this comment

Uh oh!

jesperhodge Apr 14, 2026

Choose a reason for hiding this comment

Uh oh!

jesperhodge Apr 14, 2026

Choose a reason for hiding this comment

Uh oh!

kdmccormick Apr 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kdmccormick Apr 14, 2026

Choose a reason for hiding this comment

Uh oh!

jesperhodge Apr 14, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

jesperhodge commented Apr 8, 2026 •

edited

Loading

openedx-webhooks commented Apr 8, 2026 •

edited

Loading

kdmccormick left a comment •

edited

Loading

kdmccormick Apr 14, 2026 •

edited

Loading