Conversation
What was broken Launched challenges with schedule updates could apply the wrong incoming phase payload when multiple challenge phase rows shared a phase definition id. That could make edited end dates and minute durations appear to revert after save for some timelines. Root cause (if identifiable) populatePhasesForChallengeUpdate matched incoming phase edits only by phaseId, which identifies the phase definition rather than the persisted challenge phase row. What was changed Added a phase update lookup that prefers the persisted challenge phase id and falls back to the existing phaseId behavior for compatibility. Kept the existing scheduledEndDate duration recalculation behavior intact. Fixed a missing Chai binding in challenge-helper tests so the unit command can load that file. Any added/updated tests Added phase-helper regression coverage for launched open phases that share a phase definition id and must preserve distinct scheduledEndDate and duration updates.
What was broken Active phase end dates could only move later. The API rejected shortening even for Design challenges, and direct phase updates only recalculated successor schedules when an end date was extended. Root cause The phase validation did not account for challenge track, and successor recalculation used an extended-only check. What was changed Added track-aware active phase end-date validation that allows Design track shortening while blocking end dates before the current date/time. Wired it into challenge updates and direct phase updates, and recalculated dependent phases whenever the active end date changes. Any added/updated tests Added phase-helper coverage for Design shortening, non-Design rejection, and past end-date rejection. Added a ChallengePhaseService regression test for Design shortening and successor schedule recalculation.
PM-5361: Preserve phase schedule updates by id
PM-5378: Allow Design active phase shortening in API
What was broken The previous fix only allowed Design-track shortening for the currently open phase. Active non-Design schedule validation could also reject unchanged saved end dates when a stale duration from the Work app implied shortening, and phase update matching did not use challenge phase row ids. Root cause The PM-5378 guard was keyed to phase.isOpen instead of the active challenge schedule as a whole. The update helper also had a row-id-aware matcher but still used phase definition ids in the main update path. What was changed Design challenges can now shorten any incomplete phase, provided the requested end date is not before the current date/time. Active non-Design challenges now guard every incomplete phase against shortening, while pre-launch non-Design reductions remain allowed. Full challenge updates and direct phase PATCHes both pass the active-challenge guard options, and challenge phase updates now prefer row id matching before phase definition id matching. Any added/updated tests Bootstrapped the phase helper test and added regressions for Design future-phase shortening, active non-Design future-phase rejection, pre-launch non-Design shortening, and stale duration payloads that keep the persisted end date. Focused phase-helper tests and pnpm lint passed. Full pnpm test is blocked without DATABASE_URL, and pnpm build is unavailable because the package has no build script.
PM-5378: Allow Design shortening across phases
What was broken Direct phase updates could include both an explicit scheduledEndDate and a stale duration. The stale duration won, recalculating the end date and causing active challenge edits to be rejected or saved with the wrong duration. Root cause ChallengePhaseService.partiallyUpdateChallengePhase treated any duration in the payload as authoritative before considering a user-selected scheduledEndDate. What was changed When scheduledEndDate is provided, derive duration from the phase start and that explicit end date. Only derive scheduledEndDate from duration when no explicit end date is present. Kept the phase-helper regression fixture dates in the future so current-time validation remains deterministic. Any added/updated tests Added ChallengePhaseService coverage for explicit scheduledEndDate taking precedence over stale duration. Updated the PM-5378 phase-helper regression fixture dates.
PM-5378: Preserve explicit phase end dates
What was broken Active Development challenge edits could still be rejected with the Design-only shortening error when a user moved a phase start earlier, or switched the challenge start to Immediately, while keeping the phase duration unchanged. Root cause The active phase schedule guard compared the requested scheduled end date only against the persisted end date. When the start date also moved earlier, an unchanged-duration phase had an earlier end date and was incorrectly classified as a shortened phase. What was changed The phase helper now resolves the requested scheduled start date before validation and treats a non-Design active update as shortening only when the requested phase duration is actually reduced. The direct phase PATCH path now passes the same requested start-date context to the shared validation. Any added/updated tests Added phase-helper regression coverage for allowing active non-Design phase start shifts when duration is unchanged, and for still rejecting active non-Design updates that reduce duration after moving the start earlier.
PM-5378: Allow unchanged-duration active schedule shifts
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.