Fix integrity error handling

[jesperhodge]

Fixes openedx/modular-learning#261

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]

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:

• Overview of Review Process for Community Contributions
• Pull Request Status Guide
• Making changes to your pull request

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]

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]

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]

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]

Thanks for the comprehensive tests.

[kdmccormick]

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

[kdmccormick]

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]

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.