Conversation
What was broken Marathon Match submitter exports could show negative failed-run scores, finalScore values while a challenge was still in submission, and a finalRank column before the challenge was completed. Root cause The challenge export SQL treated any final score field as exportable regardless of challenge status, used negative review summation scores as normal scores, and always emitted Marathon Match final columns from the formatter. What was changed Changed the submitter, valid submitter, and winner SQL to ignore negative Marathon Match scores, only expose finalScore/finalRank data for completed challenges, and avoid falling back to submission.finalScore when a final review row explicitly failed. Updated the challenge report formatter so Marathon Match finalScore and finalRank columns are only emitted when at least one row has those values. Updated report descriptions and DTO documentation to match the completed-only final data behavior. Any added/updated tests Updated the challenge SQL regression spec for completed-only final scores, negative score filtering, and completed-only final ranks. Added a service regression test that verifies active Marathon Match exports omit finalScore and finalRank columns when final scoring is unavailable.
What was broken The previous PM-4151 follow-up suppressed active Marathon Match final columns and negative scores, but the final score fallback still depended on final_review.aggregateScore being non-null. If a final review row exists without a valid non-negative score, the query could still fall back to stale submission.finalScore. Root cause The final review lateral subquery only projected aggregateScore, so the scoring CASE could not distinguish no final review row from a final review row that exists but is not usable for export. What was changed Projected a has_final_review flag from the final review lateral subqueries for submitter, valid submitter, and winner exports. The Marathon Match final score CASE now falls back to submission.finalScore only when no final review row exists, while existing final review rows with negative or otherwise unusable scores export null. Any added/updated tests Updated the challenge export SQL regression spec to require the final review presence guard across submitter, valid submitter, and winner SQL.
What was broken The previous PM-4151 follow-up suppressed active Marathon Match final columns and guarded final review fallbacks, but failed or deleted Marathon Match submissions could still influence score output. Positive initialScore/finalScore fallbacks from failed submissions could leak stale scores, and a newest failed submission with no usable score could mask an earlier valid scored run. Root cause The challenge export SQL filtered negative review summation scores, but the submission.initialScore and submission.finalScore fallback paths did not check reviews.submission.status. The submitter and valid submitter ranking CTEs also selected the newest submission before checking whether it had any usable Marathon Match score. What was changed Added failed/deleted submission status guards before using Marathon Match provisional and final score fallbacks in submitter, valid submitter, and winner exports. Changed Marathon Match submitter and valid submitter score selection to skip rows where both provisionalScore and finalScore are unavailable, so the latest usable scored run is used instead of a failed no-score run. Updated the challenge user DTO documentation to describe the latest non-failed scored submission behavior. Any added/updated tests Updated src/reports/challenges/challenge-export-sql.spec.ts to cover failed/deleted status guards, provisional initialScore fallback, and latest usable score selection for Marathon Match submitter exports.
What was broken The previous PM-4151 follow-up blocked failed/deleted Marathon Match submissions and guarded final score fallback, but a failed provisional review row could still leak stale score data. If the latest provisional review summation had a negative score, the SQL filtered that row out before fallback logic and then used submission.initialScore or an older positive provisional row. Root cause The provisional review lateral queries only selected non-negative reviewSummation rows, so the CASE expression could not distinguish no provisional review from a latest failed provisional review. The final score path already had a has_final_review guard, but the provisional score path did not have the same guard. What was changed Added a has_provisional_review guard to submitter, valid submitter, and winner exports. The reports now use the latest provisional review row, return the score only when that row is non-negative, and only fall back to submission.initialScore when no provisional review row exists. Any added/updated tests Updated src/reports/challenges/challenge-export-sql.spec.ts to assert the provisional review guard and prevent pre-filtering negative provisional review rows before fallback logic runs.
PM-4151: guard MM provisional review fallback
What was broken The previous PM-4151 fixes made submitter and valid submitter exports choose the latest usable Marathon Match scored submission, but the winners export still aggregated all historical submission scores with MAX(). That could expose an older high provisional or final score for a winner after a later scored run existed. Root cause The winners SQL kept a separate Marathon Match score CTE that grouped by member and selected MAX(provisional_score) and MAX(final_score_raw). That bypassed the latest-submission selection pattern added to the other challenge export queries. What was changed Updated the winners export to select the latest usable Marathon Match scored submission by submission timestamp and submission id before rounding/exporting provisionalScore and finalScore. Updated the Reports Portal description for Challenge Winners to document the latest non-failed provisionalScore behavior. Any added/updated tests Updated src/reports/challenges/challenge-export-sql.spec.ts to assert all challenge user exports use DISTINCT ON latest scored submissions and do not aggregate Marathon Match provisional/final scores with MAX().
PM-4151: use latest MM winner scores
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.