Conversation
What was broken Private engagement updates could still reject reassigning the same member when the request included both a historical completed or terminated assignment row and the new assignment row. The update flow also treated a single same-member row as matching historical assignment data in the prior fix, which could avoid creating the new active assignment. Root cause The assignment update logic compared duplicate private assignment payload rows directly against the required member count and matched incoming rows to assignments without separating active slots from terminal history. That left terminal history rows competing with new active assignment rows for uniqueness and mutation planning. What was changed Added assignment mutation planning for private engagement updates that groups rows by member, preserves terminal assignment history, updates existing active rows, creates one new active row when reassignment is valid, and terminates omitted active rows by assignment id. Allowed duplicate member rows only inside the private assignment update planner so duplicate active assignments are still rejected. Aligned stale e2e expectations with the current application route and active-assignment filtering so the full test command runs cleanly. Any added/updated tests Added engagement service coverage for duplicate payload rows with a completed historical assignment. Added coverage for creating a new assignment when the previous same-member assignment is completed or terminated and only the new row is submitted. Updated e2e expectations for current route and active-assignment query behavior.
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.
What was broken
Private engagement updates could still reject reassigning the same member when the request included both a historical completed or terminated assignment row and the new assignment row.
The prior backend fix also had a gap where a single same-member reassignment row could be matched to terminal history instead of creating the new active assignment.
Root cause
The private assignment update flow compared duplicate payload rows directly against the required member count and matched incoming rows without separating active assignment slots from completed or terminated history.
That made historical rows compete with valid new assignment rows and still allowed duplicate-active checks to reject the reassignment path QA tested.
What was changed
Added assignment mutation planning for private engagement updates that groups rows by member, preserves terminal history, updates existing active rows, creates one new active row when reassignment is valid, and terminates omitted active rows by assignment id.
Duplicate member rows are now allowed only inside the private assignment update planner, while duplicate active assignments for the same member remain rejected.
Aligned stale e2e expectations with the current application route and active-assignment filtering so the full project test command runs cleanly.
Any added/updated tests
Added engagement service coverage for duplicate payload rows with a completed historical assignment.
Added coverage for creating a new assignment when the previous same-member assignment is completed or terminated and only the new row is submitted.
Updated e2e expectations for the current application route and assigned-member private engagement query behavior.
Validation
source ~/.nvm/nvm.sh && nvm use && pnpm lintsource ~/.nvm/nvm.sh && nvm use && pnpm buildsource ~/.nvm/nvm.sh && nvm use && pnpm test -- src/engagements/engagements.service.spec.tssource ~/.nvm/nvm.sh && nvm use && pnpm test