Repository navigation
Special limits - #1731
Special limits#1731
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1731 +/- ##
==========================================
+ Coverage 56.72% 56.84% +0.12%
==========================================
Files 344 344
Lines 28314 28360 +46
==========================================
+ Hits 16060 16122 +62
+ Misses 12254 12238 -16
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
This seems reasonable to me, but why not call the fields |
Add nullable override_time_limit and override_mem_limit columns to submissions. When set, EvaluationJob.from_submission runs the submission with these (usually larger) limits instead of the dataset's ones.
Good idea. Changed. |
prandla
left a comment
There was a problem hiding this comment.
LGTM other than the one nitpick
We would like a way for administrators to run submissions with increased time / memory limits. This would be very useful for unit tests as well as for testing specific submissions during the contest. This pull request would add two optional fields to each submission specifying the special time and memory limits. They can only be set by submitting a solution via api as an administrator.
It is theoretically possible to emulate this behavior by creating extra datasets with different limits, but one would have to manually trigger an evaluation of the submission on the dataset, and it seems quite error-prone and confusing.
I wasn't sure what database updaters would need to be written. (Maybe none as we are only adding two fields, which have default values?)
There is no indication of the special time / memory limits in the admin interface. We'd be happy to add some if you like.
One thing one needs to be aware of is that this in interactive tasks, the controller wall limit is not automatically adjusted to accommodate the larger solution time limit. But we think it can be set to a large value in the first place as it seems to be only a guard against controller bugs.
The code was written with @PH111P.