Keep track of potential first to solves so we can update them when we get 'delayed' results. #2282
Conversation
| // If there are no valid correct submissions submitted earlier but there | ||
| // are submissions awaiting judgement, we are potentially the first to solve. | ||
| // We need to keep track of this since we later need to set the actual first to solve. | ||
| $verificationRequiredExtra = ($verificationRequired && !$useExternalJudgements) ? 'OR j.verified = 0' : ''; |
There was a problem hiding this comment.
External judgements don't have a verified status in this sense. This just never worked.
nickygerritsen
force-pushed
the
first-to-solve-delayed
branch
2 times, most recently
from
9247b71 to
1c3b93e
Compare
| public function up(Schema $schema): void | ||
| { | ||
| // this up() migration is auto-generated, please modify it to your needs | ||
| $this->addSql('ALTER TABLE scorecache ADD is_potential_first_to_solve TINYINT(1) DEFAULT 0 NOT NULL COMMENT \'Is this potentially the first solution to this problem?\' AFTER is_first_to_solve'); |
There was a problem hiding this comment.
This seems to require a _public and _jury version: if you first solve a problem in the freeze and there's another one pending before yours, but also in the freeze, then the public/team should not know whether it was actually a first to solve or not.
In general, I'm a bit wary of adding extra complexity and columns. I think it would be better if we can figure out what scoreboard data depends what changes, and just fetch all that data and pass it to a single function that just recalculates the relevant scoreboard data.
There was a problem hiding this comment.
But we also don’t have a jury and public version of the normal first to solve. So I’m wondering if we have some logic, where we don’t show it if there are blue boxes anyway?
I get what you mean but I’m not sure how to solve this easily. A new incorrect submission can affect a correct submission that came after it and currently we only handle the current submission, not any other
| ->select('s', 't') | ||
| ->andWhere('s.contest = :contest') | ||
| ->andWhere('s.problem = :problem') | ||
| ->andWhere('s.is_potential_first_to_solve = 1') |
There was a problem hiding this comment.
Is this restriction actually adding anything? We are hopefully only very rarely executing this codepath anyway, so it would not hurt to go here over all teams
- which have solved this problem (which is a restriction you are currently not adding)
- after us (right?)
There was a problem hiding this comment.
We only set s. is_potential_first_to_solve if that team solved the problem and we have earlier pending submissions, so I'd say that we do filter on teams solving this problem.
My current code assumes that if we loop over all potentional first to solves for the same problem, we will find the one that we need to actually update.
Currently this code path is executed more than you think: it is executed when we have no pending jury submissions for this (team,problem) and we are not the first to solve ourselves.
If you have a better idea to implement this, I am open, but I don't follow your thought currently. Feel free to push it as a commit. I think the added test should catch if it works.
There was a problem hiding this comment.
I am thinking of something like 76f1640
That should make sure we don't call it too often while not adding the complexity of the extra column. I still have to think through the potential race conditions...
There was a problem hiding this comment.
Something like that could indeed work I think.
… get 'delayed' results. Fixes DOMjudge#2281.
meisterT
force-pushed
the
first-to-solve-delayed
branch
from
1c3b93e to
5e1442b
Compare
… when we get 'delayed' results." This reverts commit 9f4dcc0. DOMjudge#2282 was merged by accident and needs more thought.
Fixes #2281.
I don't know why we never found this before, but I think this scenario is real and I see no other easy way to fix this.
I have split up the logic of determining first to solve in two:
Then when we update a score cache entry with 0 pending items, we need to consider that we need to check submissions from other teams for the same problem, to see if they have any potential first to solve submissions and recalculate them.
This brings with it a performance penalty every time we update the score cache with 0 pending submissions, since we need to query for the same contest and problem all score caches with a potential first to solve. There is currently no index on this column, but there are indices on the contest, team and problem columns, so I think this should not be a big overhead. If it turns it this is an issue, we can add an index on
cid, probid, is_potential_first_to_solve. The next extra overhead is when there are actually pending first to solves, since then we need to recalculate them. But I think this makes sense, since this is exactly what we try to solve.I first wrote the testcase, which fails without my fix. If you add
$scoreboardService->calculateScoreRow($contest, $team2, $problem);below the second$scoreboardService->calculateScoreRow($contest, $team1, $problem);it does succeed without my change, since then we do indeed update the data.