[HnR-Autograder:3] Chain persistence

[Elimpizza]

This pull request significantly enhances the handling of auto-grading configurations for assignments, enabling support for multiple grading phases and improving robustness and test coverage. The core logic now allows storing and retrieving chains of auto-grading configs, each representing a grading phase, and ensures correct cleanup and reuse of configs when assignments are updated.

The most important changes are:

Auto-Grading Configs: Multi-Phase Support and Management

• Added support for storing and retrieving multiple auto-grading configurations per assignment, each representing a grading phase, chained via previous_config_id. Introduced the _MAX_CHAIN_DEPTH constant to prevent infinite cycles in config chains. (lms/services/assignment.py) [1] [2]
• Updated the update_assignment and _update_auto_grading_config methods to accept and correctly handle a list of config dicts (one per phase), including logic to reuse, drop, or delete configs as needed. (lms/services/assignment.py) [1] [2]

Testing: Expanded Coverage for Multi-Phase Logic

• Added comprehensive unit tests to verify multi-phase config storage, retrieval, chain ordering, config reuse, deletion, and cycle protection. (tests/unit/lms/services/assignment_test.py)
• Added a functional test to ensure that a single-phase auto-grading config is correctly persisted from an LTI launch. (tests/functional/views/lti/basic_lti_launch_test.py)

Imports and Minor Cleanups

• Updated imports to include AutoGradingConfig and json where needed for new test logic. (tests/functional/views/lti/basic_lti_launch_test.py, tests/unit/lms/services/assignment_test.py) [1] [2] [3]

These changes collectively provide a robust foundation for assignments with complex, multi-phase auto-grading workflows.This pull request significantly extends the assignment auto-grading configuration system to support multiple grading phases, each with its own configuration, and ensures robust handling and testing of these changes. The main focus is on allowing an assignment to have a chain of auto-grading configurations rather than just one, improving flexibility for complex grading workflows.

The most important changes are:

Core functionality enhancements:

• lms/services/assignment.py: The AssignmentService now supports multiple auto-grading phases by storing a chain of AutoGradingConfig objects linked by previous_config. The new method get_auto_grading_configs retrieves these configs in phase order, and _update_auto_grading_config is refactored to handle a list of configs, adding, updating, or removing phases as needed. A recursion limit (MAX_AUTO_GRADING_PHASES) is introduced to prevent infinite loops from cycles. [1] [2] [3] [4]

Testing improvements:

• tests/unit/lms/services/assignment_test.py: Comprehensive tests are added for the new multi-phase auto-grading logic, including tests for correct ordering, chain isolation, handling of unflushed configs, recursion bounds, config updates, phase reuse, phase dropping, and complete removal of configs.

API and interface changes:

• lms/services/assignment.py: The auto_grading_config parameter in update_assignment and related methods now accepts either a single dict or a list of dicts, reflecting support for multiple phases. [1] [2]

Constants and imports:

• lms/services/assignment.py, tests/unit/lms/services/assignment_test.py: The new constant MAX_AUTO_GRADING_PHASES is defined and imported in tests to bound the grading phase chain traversal. [1] [2]

These changes collectively make the assignment auto-grading system more flexible and robust, with thorough tests to ensure correctness and prevent regressions.

[karenrasmussen]

There’s no cap on len(phases) — only the read side is bounded. So a config with 100 phases would write all 100 rows, but get_auto_grading_configs would only ever read back the first 20. This could happen through the deep-linking launch path.

[Elimpizza]

Thanks! on it!