fix(call-timer): resolve-main-consult-conference-hold-timer-discrepancies - #569
Conversation
|
This pull request is automatically being deployed by Amplify Hosting (learn more). |
adhmenon
left a comment
adhmenon
left a comment
There was a problem hiding this comment.
Just few comments on a small logic change, if possible.
| /** | ||
| * Timestamp when post-call state started. | ||
| */ | ||
| postCallTimestamp?: number; |
There was a problem hiding this comment.
I feel we should not have so many timestamp props.
We should just have 2 - one for the state timer and one for consult timer.
The value can be calculated in Utils and passed into the prop.
There was a problem hiding this comment.
Addressed - Reduced timestamp props from 7 to 4 as requested:
- State timer: stateTimerLabel + stateTimerTimestamp
- Consult timer: consultTimerLabel + consultTimerTimestamp
Removed redundant props: consultStartTimeStamp, wrapUpTimestamp, postCallTimestamp, consultHoldTimestamp
All timestamp calculations moved to timer-utils.ts (calculateStateTimerData and calculateConsultTimerData functions).
| // Get holdTimestamp - prioritize consult hold over main call hold | ||
| // This ensures the hold timer shows the correct time for whichever call is currently on hold | ||
| const consultHoldTs = currentTask?.data?.interaction | ||
| ? findHoldTimestamp(currentTask.data.interaction, 'consult') | ||
| : null; | ||
| const mainCallHoldTs = currentTask?.data?.interaction | ||
| ? findHoldTimestamp(currentTask.data.interaction, 'mainCall') | ||
| : null; | ||
|
|
||
| if (holdTimestamp) { | ||
| const holdTimeMs = holdTimestamp < 10000000000 ? holdTimestamp * 1000 : holdTimestamp; | ||
| // Use consult hold timestamp if available, otherwise use main call hold timestamp | ||
| const activeHoldTimestamp = consultHoldTs || mainCallHoldTs; | ||
|
|
||
| if (activeHoldTimestamp) { | ||
| const holdTimeMs = activeHoldTimestamp < 10000000000 ? activeHoldTimestamp * 1000 : activeHoldTimestamp; |
There was a problem hiding this comment.
As mentioned above - we cna move a lot of this logic into the Utils file...
There was a problem hiding this comment.
Addressed - Hold timer logic moved to Utils/useHoldTimer.ts as a custom hook.
- Extracted all worker management, cleanup, and timestamp logic (65+ lines)
- Worker script defined at module level for optimal performance
- Hook returns holdTime value, auto-updates on currentTask changes
- Includes comprehensive unit tests
| const [consultStartTimeStamp, setConsultStartTimeStamp] = useState<number>(0); | ||
| const [wrapUpTimestamp, setWrapUpTimestamp] = useState<number>(0); | ||
| const [postCallTimestamp, setPostCallTimestamp] = useState<number>(0); | ||
| const [consultHoldTimestamp, setConsultHoldTimestamp] = useState<number>(0); | ||
|
|
||
| // State timer labels and timestamps | ||
| const [stateTimerLabel, setStateTimerLabel] = useState<string | null>(null); | ||
| const [stateTimerTimestamp, setStateTimerTimestamp] = useState<number>(0); |
There was a problem hiding this comment.
Right - rather than using all these states, is it possible to just use 2 - one for state and other for consult. Then we can get the value by migrating that logic into utils.
That ways we can reduce the number of states. Labels are alright - we need 2 anyways.
There was a problem hiding this comment.
Addressed - Reduced to exactly 2 timestamp states (+ 2 labels) as requested:
Before: 8 states (4 intermediate timestamps + 4 final timer states)
- consultStartTimeStamp, wrapUpTimestamp, postCallTimestamp, consultHoldTimestamp
- stateTimerLabel, stateTimerTimestamp, consultTimerLabel, consultTimerTimestamp
After: 4 states (2 timestamps + 2 labels)
- stateTimerTimestamp + stateTimerLabel
- consultTimerTimestamp + consultTimerLabel
All calculation logic migrated to timer-utils.ts (calculateStateTimerData & calculateConsultTimerData)
| } else { | ||
| setConsultHoldTimestamp(0); | ||
| } | ||
| }, [currentTask, agentId, extractConsultingAgent]); |
There was a problem hiding this comment.
Same for these methods, maybe move to a Util and then just update the timestamp and inject that as a prop rather than multiple ones.
3 participants
COMPLETES #https://jira-eng-sjc12.cisco.com/jira/browse/CAI-7396
Vidcast link: https://app.vidcast.io/share/9da711ea-687d-481f-9001-8ac74c6a2df3
This pull request addresses
The proper handling of wrap-up, post-call, consulting, and consult-on-hold timers along with their corresponding labels during the main call flow. It ensures timer visibility and synchronization are aligned with Agent Desktop behavior.
by making the following changes
< DESCRIBE YOUR CHANGES >
Change Type
The following scenarios were tested
< ENUMERATE TESTS PERFORMED, WHETHER MANUAL OR AUTOMATED >
The GAI Coding Policy And Copyright Annotation Best Practices
Checklist before merging
Make sure to have followed the contributing guidelines before submitting.