feat: implement XqueueViewSet with full xqueue-watcher compatibility

- Add XqueueViewSet with complete xqueue-watcher service compatibility

- Implement get_submission service for retrieving pending submissions

- Add put_result service with row-level locking (select_for_update(nowait=True)) to prevent race conditions

- Ensure concurrent xqueue-watcher instances process each submission exactly once, even under high load

- Implement standardized response format for backward compatibility

- Add session management and authentication handling for XWatcher clients

- Add comprehensive test coverage for core interactions

feat: Improve transaction handling to prevent concurrent processing and add timeout mechanism (Get Submission)

- Implemented locking to ensure submissions are processed by a single xqueue watcher.

- Added timeout mechanism for submissions stuck in 'pulled' state.

- Updated tests to cover new error scenarios and timeout handling.

feat: Optimize submission retrieval and processing flow

- Renamed variables from 'submission_record' to 'external_grader' throughout the

  codebase for better consistency with model naming

- Added new 'retry' status to integrate with submission processing retry services

- Removed unused 'is_processable' method that wasn't providing any value

- Enhanced test coverage

- Add new status external grader detail migration

feat: Add event emission for external grader scores

This commit adds the EXTERNAL_GRADER_SCORE_SUBMITTED event emission to the

put_result endpoint in the XQueueViewSet. When a grader submits a result and

the score is successfully saved, the system now emits an event with all the

necessary information for the LMS to render the graded XBlock.

Key changes:

- Add queue_key field to ExternalGraderDetail model

- Include queue_key in create_external_grader_detail method

- Emit EXTERNAL_GRADER_SCORE_SUBMITTED event after successful score update

- Implement robust false to propagate error and put submission in pending queue again

- Add migration for the new queue_key field

- Add openedx-events dependency

fix: persist queue_key and expose it in ExternalGraderDetail admin

This commit fixes grading flow issues caused by the missing `queue_key`

in ExternalGraderDetail records and improves overall observability of

external grader operations inside the LMS.

- `queue_key` was never passed into `ExternalGraderDetail.create_from_uuid`,

  causing the field to always be saved as `NULL`.

- As a result, the external grading pipeline was unable to deliver correct

  score updates because `score_update` requires a valid queue_key.

- The LMS received the EXTERNAL_GRADER_SCORE_SUBMITTED event, but the Block could not apply the score, leaving learners stuck on a loading spinner.

- Adds `queue_key` to the external grader creation flow so it is properly persisted in the database.

- Exposes `queue_key` in ExternalGraderDetailAdmin:

  - Added to `list_display`

  - Added to `readonly_fields`

  - Added to `search_fields`

  - Added to admin form fieldsets

  - Field remains read-only to avoid accidental modification

- External grader responses now carry a valid `queue_key`, allowing XBlocks

  to successfully execute `handle_ajax('score_update', ...)` and update scores.

- Learners no longer see an infinite loading spinner after submission.

- Admins gain full visibility into queue_key for debugging and operational

  auditing without risking accidental edits.

This enables the event-driven approach for updating XBlocks with scoring data
from the edx-submissions service, supporting the gradual migration away from
HTTP-based XQueue callbacks.

Author: leoaulasneo98

docs/source/decisions/0004-transaction-handling-in-get_submission

@@ -0,0 +1,33 @@
+Improving Transaction Handling in Get Submission
+================================================
+
+Status
+------
+
+**Provisional** *2025-03-19*
+
+Context
+-------
+
+We identified a concurrency issue in the submission processing flow. Multiple instances of the xqueue watcher were processing the same transaction simultaneously, causing duplicate handling of submissions. Additionally, submissions remained stuck in the "pulled" state indefinitely when errors or unexpected interruptions occurred during processing.
+
+Decision
+--------
+
+We introduced a robust locking mechanism at the database level to prevent concurrent processing of the same submission. Specifically, we employed database row-level locking (`select_for_update(nowait=True)`) on submissions to ensure only one xqueue watcher instance can process a transaction at a time. Additionally, we implemented a timeout-based fallback, marking submissions in the "pulled" state as available again if they exceed a defined timeout period (5 minutes).
+
+Consequences
+------------
+
+Positive
+~~~~~~~~
+
+- Ensures data consistency by preventing duplicate transaction processing.
+- Implements automatic recovery for submissions stuck in the "pulled" state, improving overall system reliability.
+- Minimal impact on system performance due to efficient database-level locking.
+
+Negative
+~~~~~~~~
+
+- Slightly increased complexity in transaction handling logic.
+- Potential minor latency increase when contention occurs due to database locks.

pylintrc

@@ -275,7 +275,7 @@ disable =
 	unspecified-encoding,
 	unused-wildcard-import,
 	use-maxsplit-arg,
-	
+
 	logging-fstring-interpolation,
 
 [REPORTS]

requirements/base.txt

@@ -4,27 +4,27 @@
 #
 #    make upgrade
 #
-asgiref==3.9.1
+asgiref==3.10.0
     # via django
 django==4.2.25
     # via
-    #   -c common_constraints.txt
-    #   -r base.in
+    #   -c requirements/common_constraints.txt
+    #   -r requirements/base.in
     #   django-model-utils
     #   djangorestframework
     #   edx-django-release-util
     #   jsonfield
 django-model-utils==5.0.0
-    # via -r base.in
+    # via -r requirements/base.in
 djangorestframework==3.16.1
-    # via -r base.in
+    # via -r requirements/base.in
 edx-django-release-util==1.5.0
-    # via -r base.in
+    # via -r requirements/base.in
 jsonfield==3.2.0
-    # via -r base.in
+    # via -r requirements/base.in
 pytz==2025.2
-    # via -r base.in
-pyyaml==6.0.2
+    # via -r requirements/base.in
+pyyaml==6.0.3
     # via edx-django-release-util
 six==1.17.0
     # via edx-django-release-util

requirements/ci.txt

@@ -8,7 +8,7 @@ cachetools==6.2.0
     # via
     #   -r requirements/tox.txt
     #   tox
-certifi==2025.8.3
+certifi==2025.10.5
     # via requests
 chardet==5.2.0
     # via
@@ -20,7 +20,7 @@ colorama==0.4.6
     # via
     #   -r requirements/tox.txt
     #   tox
-coverage[toml]==7.10.5
+coverage[toml]==7.10.7
     # via coveralls
 coveralls==4.0.1
     # via -r requirements/ci.in
@@ -57,7 +57,7 @@ pyproject-api==1.9.1
     #   tox
 requests==2.32.5
     # via coveralls
-tox==4.28.4
+tox==4.30.3
     # via -r requirements/tox.txt
 urllib3==2.5.0
     # via requests

requirements/common_constraints.txt

@@ -23,7 +23,3 @@ Django<5.0
 # elastic search changelog: https://www.elastic.co/guide/en/enterprise-search/master/release-notes-7.14.0.html
 # See https://github.com/openedx/edx-platform/issues/35126 for more info
 elasticsearch<7.14.0
-
-# Cause: https://github.com/openedx/edx-lint/issues/458
-# This can be unpinned once https://github.com/openedx/edx-lint/issues/459 has been resolved.
-pip<24.3