fix(store,samples): support multi-login hydrate and WebRTC gating#703
fix(store,samples): support multi-login hydrate and WebRTC gating#703Shreyas281299 wants to merge 3 commits into
Conversation
Add task:multiLoginHydrate handling with task-class compatibility so engaged state is hydrated reliably in mirrored sessions, and update the React sample to pass disableWebRTCRegistration while unchecking WebRTC-dependent widgets before locking their toggles. Co-authored-by: Cursor <cursoragent@cursor.com>
|
This pull request is automatically being deployed by Amplify Hosting (learn more). |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ac9c8e1f2a
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| const WEBRTC_DEPENDENT_WIDGETS = ['incomingTask', 'taskList', 'callControl', 'callControlCAD']; | ||
| const isWidgetDisabledByWebRTC = (widget: string) => | ||
| isWebRTCWidgetSelectionLocked && WEBRTC_DEPENDENT_WIDGETS.includes(widget); |
There was a problem hiding this comment.
With disableWebRTCRegistration enabled and the agent using Extension/DN, this list causes the effect below to uncheck and lock IncomingTask, TaskList, CallControl, and CAD. That SDK flag disables browser media registration, but these widgets are still the UI used to accept/select/control non-browser tasks; the widgets only special-case deviceType === 'BROWSER' for browser-specific labels/media. The sample can initialize for an Extension/DN agent and then hide all task-handling UI, so calls cannot be answered or controlled.
Useful? React with 👍 / 👎.
|
|
||
| this.registerTaskEventListeners(task); | ||
| this.refreshTaskList(); | ||
| this.handleTaskAssigned(task); |
There was a problem hiding this comment.
When task:multiLoginHydrate carries one of the SDK task-class payloads supported by the new getInteractionId()/getInteractionState() fallbacks, passing the raw object into handleTaskAssigned stores it as currentTask. The rest of the store/widgets still read task.data.*, so a class payload without legacy data will crash on the next refresh/render instead of hydrating the mirrored session; normalize to the legacy shape or keep all downstream access class-safe.
Useful? React with 👍 / 👎.
github-actions
Bot
removed
the
validated
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 94b2fe0539
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| const interactionId = this.getTaskInteractionId(task); | ||
| const interactionState = this.getTaskInteractionState(task); | ||
|
|
||
| if (interactionId && this.store.taskList[interactionId] && interactionState === 'new') { |
There was a problem hiding this comment.
When a mirrored session receives task:multiLoginHydrate for a still-ringing task that is not already in store.taskList (common on a fresh session), this condition falls through even though interactionState === 'new'. The handler then calls handleTaskAssigned, and that unconditionally sets the custom state to ENGAGED after setCurrentTask refuses the incoming task, so the agent/UI is marked engaged before the task is accepted; skip or route all new hydrate payloads through incoming-task handling instead of assignment.
Useful? React with 👍 / 👎.
| }, | ||
| cc: { | ||
| allowMultiLogin: isMultiLoginEnabled, | ||
| disableWebRTCRegistration, |
There was a problem hiding this comment.
When this SDK flag is true, the sample still renders StationLogin with hideDesktopLogin controlled only by the separate checkbox, and the StationLogin component filters the Desktop/Browser option solely from that prop. A user can therefore initialize with WebRTC registration disabled and still select browser-based calling, which the new toggle text says is prevented and which cannot register media; force hideDesktopLogin (or otherwise filter the Browser/Desktop option) whenever disableWebRTCRegistration is enabled.
Useful? React with 👍 / 👎.
1 participant
COMPLETES #https://jira-eng-sjc12.cisco.com/jira/browse/CAI-7899
This pull request addresses
Multi-login mirrored widget sessions were not consistently hydrating
ENGAGEDcustom state, and the sample React app did not expose or enforce thedisableWebRTCRegistrationbehavior for WebRTC-dependent widgets.by making the following changes
task:multiLoginHydratehandling incc-storeevent wiring, including listener registration/removal and dedupe for already-knownnewinteractionssamples-cc-react-appto passdisableWebRTCRegistrationin SDK config, add UI toggle, and uncheck WebRTC-dependent widgets before locking their selectionChange Type
The following scenarios were tested
yarn workspace @webex/cc-store exec jest tests/storeEventsWrapper.ts --runInBandyarn workspace samples-cc-react-app buildThe GAI Coding Policy And Copyright Annotation Best Practices
Checklist before merging
Make sure to have followed the contributing guidelines before submitting.
Made with Cursor