[Feature:TAGrading] Add submission clustering daemon#13004
Conversation
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #13004 +/- ##
============================================
+ Coverage 21.11% 21.16% +0.04%
+ Complexity 10104 10102 -2
============================================
Files 282 285 +3
Lines 38230 38769 +539
Branches 596 596
============================================
+ Hits 8074 8205 +131
- Misses 29574 29982 +408
Partials 582 582
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
dagemcn
left a comment
There was a problem hiding this comment.
I was able to verify the daemon is working and after sending the POST request I could see the correct output in the logs. I looked over the code but I'm not too familiar with the previous code for this project so someone that reviewed the backend PR should definitely also look at this. To clarify, is there a reason to run the php-lint before testing the backend? Also, see my other comment.
I am not sure where are we running php lint? We are running a php unit test GradingClusterControllerTester.php |
williamjallen
left a comment
There was a problem hiding this comment.
Looks pretty reasonable to me overall. I plan to approve once the inline comments are addressed. @bmcutler should probably double check the high level stuff since she knows the architecture of this part of the codebase better than I do.
There was a problem hiding this comment.
I don't know if this is an issue with your PHP test or a misunderstanding on my end, but with our current documentation I was not able to run the new PHP unit test by itself. I can run all PHP unit tests by running "submitty_test php-unit", but I get an error when running the following command in the site directory in my VM:
submitty_test php-unit --filter vendor/bin/phpunit tests/app/controllers/grading/GradingClusterControllerTester.php
And upon trying to define XDBUG_MODE=coverage in my command, I get error "Test file "XDEBUG_MODE=coverage" not found".
Other than that, I was able to follow the testing procedure and confirm using the logs that the daemon completed the clustering task after the post request. I can't really comment on the code itself, as I am not super familiar with daemon programming.
williamjallen
left a comment
There was a problem hiding this comment.
Looks good to me once the inline comment is addressed.
bmcutler
left a comment
There was a problem hiding this comment.
Why is this PR adding multiple files at the top level of sbin?
sbin is a collection of one-off superuser scripts -- many run directly by the sysadmin doing maintenance tasks. I don't think clustering should be mixed up with these files. I think clustering is a more substantial project and should be organized in its own directory.
Why is this PR editing the cleanup active graders script?
I don't like the vague naming of the 'database_queries.py' script. You've added very specific functions only used by clustering to this script. Is this a good design plan?
I previously hadn't considered the clutter in sbin/ , but I agree it should now be separated. We can create a new directory sbin/grading_clustering/ and move related files there.
My reason for touching that file was to fix Python Lint error. Both scripts needed the same database connection logic so linter was complaining about the duplicate code. If you would want I can revert that.
My rationale was to make it like a centralized file for all database queries just like we have DatabaseQueries.php. But if you would want I can create a new 'database.py' file located inside the new directory we plan to create. |
bmcutler
left a comment
There was a problem hiding this comment.
thanks for restructuring the files.
I also did a brief test as described in the message and it seems to have worked as intended.
### Why is this Change Important & Necessary? This PR adds a daemon job to support asynchronous submission clustering. ### What is the New Behavior? Now the submission clustering algorithms run asynchronously. In this PR we have also removed some the files that would not be needed now that was introduced in Submitty#12886. ### What steps should a reviewer take to reproduce or test the bug or new feature? 1. Run submitty_install 2. Run php unit test (in site folder)- vendor/bin/phpunit tests/app/controllers/grading/GradingClusterControllerTester.php 3. Run python unit test - cd /usr/local/submitty/GIT_CHECKOUT/Submitty/sbin/submitty_daemon_jobs python3 -m unittest tests/test_grading_clustering.py Test if backend is fine- 1) First inside site folder to see the logs- tail -f /var/local/submitty/logs/daemon_job_queue/$(date +%Y%m%d).txt 2) Go to any gradeable, in the browser console, hit a post request- let formData = new FormData(); formData.append('csrf_token', csrfToken); formData.append('algorithm', 'dummy_split'); fetch(buildCourseUrl(['gradeable', '<GRADEABLE_ID>', 'create_clustering']), { method: 'POST', body: formData }) .then(res => res.json()) .then(console.log); Please check the daemon log- <img width="1435" height="142" alt="image" src="https://github.com/user-attachments/assets/85cbaa8f-3a79-4add-8df9-83829fb7d71d" /> 3) Make a get request to verify the clusters formed- fetch(buildCourseUrl(['gradeable', '<GRADEABLE_ID>', 'clustering'])) .then(res => res.json()) .then(console.log); ### Automated Testing & Documentation The core Python clustering logic is covered by unit tests in `sbin/submitty_daemon_jobs/tests/test_grading_clustering.py`. The PHP Controller is covered by `tests/app/controllers/grading/GradingClusterControllerTester.php`. ### Other information Please run submitty_install before reviewing.

Why is this Change Important & Necessary?
This PR adds a daemon job to support asynchronous submission clustering.
What is the New Behavior?
Now the submission clustering algorithms run asynchronously.
In this PR we have also removed some the files that would not be needed now that was introduced in #12886.
What steps should a reviewer take to reproduce or test the bug or new feature?
Run submitty_install
Run php unit test (in site folder)-
vendor/bin/phpunit tests/app/controllers/grading/GradingClusterControllerTester.php
Run python unit test -
cd /usr/local/submitty/GIT_CHECKOUT/Submitty/sbin/submitty_daemon_jobs
python3 -m unittest tests/test_grading_clustering.py
Test if backend is fine-
First inside site folder to see the logs-
tail -f /var/local/submitty/logs/daemon_job_queue/$(date +%Y%m%d).txt
Go to any gradeable, in the browser console, hit a post request-
let formData = new FormData();
formData.append('csrf_token', csrfToken);
formData.append('algorithm', 'dummy_split');
fetch(buildCourseUrl(['gradeable', '<GRADEABLE_ID>', 'create_clustering']), {
method: 'POST',
body: formData
})
.then(res => res.json())
.then(console.log);
Please check the daemon log-

fetch(buildCourseUrl(['gradeable', '<GRADEABLE_ID>', 'clustering']))
.then(res => res.json())
.then(console.log);
Automated Testing & Documentation
The core Python clustering logic is covered by unit tests in
sbin/submitty_daemon_jobs/tests/test_grading_clustering.py. The PHP Controller is covered bytests/app/controllers/grading/GradingClusterControllerTester.php.Other information
Please run submitty_install before reviewing.