[TTAHUB-3917] Support case related to endDate calculation #2685
Conversation
nvms
requested review from
kryswisnaskas,
tommaroh,
thewatermethod,
fbonds,
hardwarehuman and
AdamAdHocTeam
|
Seems we may have another issue (pre-existing??) Screen.Recording.2025-02-26.at.5.02.05.PM.mov |
| @@ -1369,51 +1369,6 @@ describe('Recipient DB service', () => { | |||
| expect(result.map((obj) => obj.id)).toEqual([3, 2, 1]); // Sorted by endDate descending | |||
| }); | |||
|
|
|||
| it('handles undefined activityReports gracefully', () => { | |||
There was a problem hiding this comment.
Why do we remove this test? Do we still handle the null date case?
There was a problem hiding this comment.
this PR is simply a revert of what was recently introduced in order to resolve this support case
There was a problem hiding this comment.
in resolving the issue @thewatermethod found, I refactored to handle null/undefined more predictably (which appears to have been the issue all along - unpredictable sort order because of bad values), and reintroduced tests for null/undefined: cb06e9d
well that's definitely odd.. I'll try and track down why this is happening, but my assumption is that this was probably pre-existing either way, I will get this resolved update: should be good now: cb06e9d |
Description of change
Reverts more changes that happened recently related to how endDate was calculated, restoring things to how they were before.
How to test
Go to http://localhost:3000/recipient-tta-records/263/region/11/rttapa?
Search for G63912
Make sure it shows a good value for
Last TTA.Before:
After:
Additionally, make sure the issue from a previous (and related) support case is still resolved:
Issue(s)
Checklists
Every PR
Before merge to main
Production Deploy
After merge/deploy