chore: Remove deprecated code owner utilities and related tests

edx_django_utils/monitoring/README.rst

@@ -81,7 +81,6 @@ Here is how you add the middleware:
         'edx_django_utils.monitoring.MonitoringSupportMiddleware',
         'edx_django_utils.monitoring.DeploymentMonitoringMiddleware',
         'edx_django_utils.monitoring.CookieMonitoringMiddleware',
-        'edx_django_utils.monitoring.CodeOwnerMonitoringMiddleware',
         'edx_django_utils.monitoring.FrontendMonitoringMiddleware',
         'edx_django_utils.monitoring.MonitoringMemoryMiddleware',
     )
@@ -99,11 +98,6 @@ In order to use the monitoring signals, import them as follows::
 
     from edx_django_utils.monitoring.signals import monitoring_support_process_response
 
-Code Owner Custom Attribute
----------------------------
-
-See docstring for ``CodeOwnerMonitoringMiddleware`` for configuring the ``code_owner`` custom attribute for your IDA.
-
 Cookie Monitoring Middleware
 ----------------------------
 

edx_django_utils/monitoring/__init__.py

@@ -5,12 +5,6 @@
 See README.rst for additional details.
 """
 from .internal.backends import DatadogBackend, NewRelicBackend, OpenTelemetryBackend, TelemetryBackend
-from .internal.code_owner.middleware import CodeOwnerMonitoringMiddleware
-from .internal.code_owner.utils import (
-    get_code_owner_from_module,
-    set_code_owner_attribute,
-    set_code_owner_attribute_from_module
-)
 from .internal.middleware import (
     CachedCustomMonitoringMiddleware,
     CookieMonitoringMiddleware,

edx_django_utils/monitoring/docs/decisions/0001-monitoring-by-code-owner.rst

@@ -4,12 +4,25 @@ Monitoring by Code Owner
 Status
 ======
 
-Accepted
+Obsolete
+
+Superseded By
+=============
+
+* ``0005-remove-code-owner-monitoring.rst``
+
+Obsolete Reason
+===============
+
+The code-owner monitoring implementation has been removed from this package. This
+ADR is retained for historical context only.
 
 Context
 =======
 
-We originally implemented the "code_owner" custom attribute in edx-platform for split-ownership of the LMS.  See the original `ADR in edx-platform for monitoring by code owner`_.
+We originally implemented the "code_owner" custom attribute in edx-platform for
+split-ownership of the LMS.  See the original `ADR in edx-platform for monitoring
+by code owner`_.
 
 Owners wanted to be able to see transactions that they owned, in any IDA.
 
@@ -18,13 +31,19 @@ Owners wanted to be able to see transactions that they owned, in any IDA.
 Decision
 ========
 
-We will move the "code_owner" custom attribute code to these shared monitoring utilities so it is available for all IDAs.
+We will move the "code_owner" custom attribute code to these shared monitoring
+utilities so it is available for all IDAs.
 
-The ability to add a catch-all configuration if there are no other matches will also be added in follow-up work.
+The ability to add a catch-all configuration if there are no other matches will
+also be added in follow-up work.
 
 Consequences
 ============
 
-IDA owners will be able to add middleware and a Django Setting to have the same "code_owner" attribute available across all IDAs that are owned.
+IDA owners will be able to add middleware and a Django Setting to have the same
+"code_owner" attribute available across all IDAs that are owned.
 
-At this time, in the case of an IDA with split-ownership, maintenance of the Django Setting is still manual. In other words, new paths with new owners will needed to be added to the setting.  Otherwise, the catch-all (if configured) will be marked as the code owner.
+At this time, in the case of an IDA with split-ownership, maintenance of the Django
+Setting is still manual. In other words, new paths with new owners will needed to
+be added to the setting.  Otherwise, the catch-all (if configured) will be marked
+as the code owner.

edx_django_utils/monitoring/docs/decisions/0003-code-owner-for-celery-tasks.rst

@@ -4,19 +4,36 @@ Code Owner for Celery Tasks
 Status
 ------
 
-Accepted
+Obsolete
+
+Superseded By
+-------------
+
+* ``0005-remove-code-owner-monitoring.rst``
+
+Obsolete Reason
+---------------
+
+The code-owner celery decorator and related instrumentation have been removed from
+this package. This ADR is retained for historical context only.
 
 Context
 -------
 
-As detailed in the `Monitoring by Code Owner ADR`_, we were able to add a ``code_owner`` custom attribute to web transactions using a special middleware. Since middleware is not run for celery tasks (non-web transactions), this solution cannot be used.
+As detailed in the `Monitoring by Code Owner ADR`_, we were able to add a
+``code_owner`` custom attribute to web transactions using a special middleware.
+Since middleware is not run for celery tasks (non-web transactions), this solution
+can not be used.
 
 .. _Monitoring by Code Owner ADR: https://github.com/openedx/edx-platform/blob/master/lms/djangoapps/monitoring/docs/decisions/0001-monitoring-by-code-owner.rst
 
 Decision
 --------
 
-We implemented a ``@set_code_owner_attribute`` decorator that would add the ``code_owner`` custom attribute for a celery task, and added the decorator to all the celery tasks.  See the `celery section of the code_owner how-to`_ for usage details.
+We implemented a ``@set_code_owner_attribute`` decorator that would add the
+``code_owner`` custom attribute for a celery task, and added the decorator to all
+the celery tasks.  See the `celery section of the code_owner how-to`_ for usage
+details.
 
 .. _celery section of the code_owner how-to: https://github.com/openedx/edx-django-utils/blob/6ed6de25d487314faa01ed72afd190db95afd1e8/edx_django_utils/monitoring/docs/how_tos/add_code_owner_custom_attribute_to_an_ida.rst#handling-celery-tasks
 
@@ -29,15 +46,25 @@ Consequences
 (Rejected) Alternatives
 -----------------------
 
-Celery has a `task_prerun signal`_ that would allow us to execute code every time a task is about to start.
+Celery has a `task_prerun signal`_ that would allow us to execute code every time
+a task is about to start.
 
-This possibility was discovered after we had already annotated tasks. We hoped this would ensure all celery tasks were automatically handled rather than requiring explicit decorators. However, when we `trialed the task_prerun approach <https://github.com/openedx/edx-platform/pull/33180>`_ we discovered that no attribute was set on the Celery tasks. This seems to be because New Relic instruments the task function itself with transaction-start and transaction-end calls, so any signals that are run before or after the task execution occur outside the scope of the transaction.
+This possibility was discovered after we had already annotated tasks. We hoped this
+would ensure all celery tasks were automatically handled rather than requiring
+explicit decorators. However, when we `trialed the task_prerun approach <https://github.com/openedx/edx-platform/pull/33180>`_ we discovered that no attribute was
+set on the Celery tasks. This seems to be because New Relic instruments the task
+function itself with transaction-start and transaction-end calls, so any signals
+that are run before or after the task execution occur outside the scope of the
+transaction.
 
-Theoretically, we could do something similar to New Relic's monkeypatching in order to inject a code owner attribute call, but this would be fragile and could lead to disruptive failures.
+Theoretically, we could do something similar to New Relic's monkeypatching in order
+to inject a code owner attribute call, but this would be fragile and could lead to
+disruptive failures.
 
 .. _task_prerun signal: https://docs.celeryproject.org/en/stable/userguide/signals.html#task-prerun
 
 Changelog
 ---------
 
-* 2023-09-19: Updated ``task_prerun`` alternative with results of a failed attempt at using it.
+* 2023-09-19: Updated ``task_prerun`` alternative with results of a failed attempt
+  at using it.

edx_django_utils/monitoring/docs/decisions/0004-code-owner-theme-and-squad.rst

@@ -4,27 +4,48 @@ Code Owner Theme and Squad
 Status
 ------
 
-Accepted
+Obsolete
+
+Superseded By
+-------------
+
+* ``0005-remove-code-owner-monitoring.rst``
+
+Obsolete Reason
+---------------
+
+The related code-owner custom attributes were removed from this package. This ADR
+is retained for historical context only.
 
 Context
 -------
 
-As detailed in the `Monitoring by Code Owner ADR`_, we added a ``code_owner`` custom attribute for monitoring by code owner. The value for this attribute had the format 'theme-squad'.
+As detailed in the `Monitoring by Code Owner ADR`_, we added a ``code_owner``
+custom attribute for monitoring by code owner. The value for this attribute had the
+format 'theme-squad'.
 
-The problems with this configuration is that for theme name changes, or when squads transfer themes, any monitoring referencing the full name would also need to be updated.
+The problems with this configuration is that for theme name changes, or when squads
+transfer themes, any monitoring referencing the full name would also need to be
+updated.
 
 .. _Monitoring by Code Owner ADR: https://github.com/openedx/edx-platform/blob/master/lms/djangoapps/monitoring/docs/decisions/0001-monitoring-by-code-owner.rst
 
 Decision
 --------
 
-We will add a ``code_owner_squad`` custom attribute. Monitoring will now be able to refer to ``code_owner_squad`` with a value of 'squad', and will be unaffected by theme name changes.
+We will add a ``code_owner_squad`` custom attribute. Monitoring will now be able
+to refer to ``code_owner_squad`` with a value of 'squad', and will be unaffected
+by theme name changes.
 
-Additionally, we are adding ``code_owner_theme`` for similar convenience if there is a need for theme-based monitoring.
+Additionally, we are adding ``code_owner_theme`` for similar convenience if there
+is a need for theme-based monitoring.
 
-We will leave the original ``code_owner`` custom attribute for backward compatability, and for cases where theme and squad are not used.
+We will leave the original ``code_owner`` custom attribute for backward
+compatibility, and for cases where theme and squad are not used.
 
 Consequences
 ------------
 
-* Theme name changes may now result in a one time fix for those that were relying on ``code_owner``. Monitoring can switch from ``code_owner`` to ``code_owner_squad``, rather than a change for every theme update in the future.
+* Theme name changes may now result in a one time fix for those that were relying
+  on ``code_owner``. Monitoring can switch from ``code_owner`` to
+  ``code_owner_squad``, rather than a change for every theme update in the future.

edx_django_utils/monitoring/docs/decisions/0005-remove-code-owner-monitoring.rst

@@ -0,0 +1,53 @@
+Remove Code Owner Monitoring
+============================
+
+Status
+------
+
+Accepted
+
+Date
+----
+
+2026-08-11
+
+Context
+-------
+
+Code-owner monitoring functionality in this package was originally introduced for
+specific operational needs and later adopted in Open edX services. The maintainers
+have since migrated away from this approach and no longer need these package-level
+helpers.
+
+The deprecated code-owner components also add ongoing maintenance overhead:
+
+* public API exports for code-owner middleware and helper methods
+* celery decorator-based instrumentation guidance
+* dedicated scripts and tests tied to New Relic and code-owner mappings
+* historical ADRs that no longer describe the active architecture
+
+Decision
+--------
+
+We will remove code-owner monitoring implementation and related integration
+artifacts from this package.
+
+We will retain historical ADRs and mark them obsolete instead of deleting them:
+
+* ``0001-monitoring-by-code-owner.rst``
+* ``0003-code-owner-for-celery-tasks.rst``
+* ``0004-code-owner-theme-and-squad.rst``
+
+Consequences
+------------
+
+* The following functionality is no longer provided by this package:
+
+  * ``CodeOwnerMonitoringMiddleware``
+  * ``set_code_owner_attribute``
+  * ``set_code_owner_attribute_from_module``
+  * ``get_code_owner_from_module``
+
+* Code-owner-specific scripts, tests, and how-to docs are removed.
+* Existing consumers must use their own instrumentation approach where needed.
+* Historical decision records remain available and clearly marked obsolete.