Conversation
What was broken Development challenges that use the standard Submission phase did not update the derived submission start/end date fields when phase schedules changed. Root cause (if identifiable) The API already had Submission in the priority list, but the response enrichment and Prisma update conversion only checked the first two priority entries: Topgear Submission and Topcoder Submission. What was changed Updated both challenge response enrichment and Prisma phase conversion to select any phase in the submission priority list, including standard Submission. Any added/updated tests Added unit tests for response enrichment and Prisma phase conversion with a standard Submission phase.
What was broken Challenge listing and detail responses used stored submission counters that represented every submission attempt. Members with multiple attempts inflated the Community app submission badge. Root cause The challenge response relied on Challenge.numOfSubmissions and Challenge.numOfCheckpointSubmissions counters instead of deriving the latest-member count from review submissions. What was changed Challenge search and detail responses now override submission counters from the review submission table by counting distinct submitting members per challenge and submission type. If the review count lookup is unavailable, the API keeps the stored counters so challenge reads still succeed. Any added/updated tests Added a ChallengeService regression test that inserts repeated contest and checkpoint submissions, then verifies both challenge detail and listing responses return latest-member counts.
PM-5138: Sync standard submission phase dates
PM-4831: Count latest member submissions
What was broken Challenge update requests could include edited phase scheduledEndDate values, but the API dropped those fields during sanitization and recalculated phase ends from the previous duration. Root cause (if identifiable) The earlier PM-5138 fix updated derived submission date mapping, but the challenge update path still only allowed scheduledStartDate and duration through for phases. When Work sent an edited registration or submission end date, populatePhasesForChallengeUpdate never saw it. What was changed Allowed scheduledEndDate in the challenge update phase schema and sanitizer. Phase schedule recalculation now applies an explicit scheduledEndDate when provided, derives duration from the resulting start/end range, and cascades successor starts from the preserved predecessor end. Any added/updated tests Added phase-helper unit coverage for Development-style Registration/Submission phases and MM Registration/MM Submission phases with edited scheduled end dates.
PM-5138: Preserve schedule end date updates
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.
https://topcoder.atlassian.net/browse/PM-5138
https://topcoder.atlassian.net/browse/PM-4831