Treat CampaignContactUpdated tasks as preview reservations

isCampaignPreviewReservation() only checks for AgentOfferCampaignReservation, but the CAMPAIGN_CONTACT_UPDATED branch in TaskManager keeps the same preview task alive and re-emits it as TASK_CAMPAIGN_PREVIEW_RESERVATION. After a skip/remove update, that task is no longer filtered in handleIncomingWebCall, so a subsequent WebRTC incoming call can be mapped/emitted as TASK_INCOMING for a still-unaccepted preview task, causing incorrect call-task association and premature ringing.

Useful? React with 👍 / 👎.

Encode campaign names before building dialer preview URLs

The preview dialer endpoints interpolate campaignId directly into the URL path, but this field is documented as a campaign name (not a UUID). If the name contains reserved characters (for example spaces, /, #, or ?), accept/skip/remove requests are sent to a malformed path or wrong route, resulting in avoidable API failures for valid campaign names.

Useful? React with 👍 / 👎.

URL-encode campaignId (and interactionId) before interpolating into the path.

campaignId is documented as a campaign name, not a UUID. If the name contains reserved URL characters (spaces, /, #, ?, etc.), this produces a malformed path or routes to the wrong endpoint.

Suggested fix — apply to all three preview URLs (accept, skip, remove):

url: `${DIALER_API}/campaign/${encodeURIComponent(p.data.campaignId)}/preview-task/${encodeURIComponent(p.data.interactionId)}${CAMPAIGN_PREVIEW_ACCEPT}`,

Missing test for URL encoding of campaignId.

The URL-construction tests only use a clean campaignId (TestCampaignPreview). Once encodeURIComponent is added to the URL building (see comment on dialer.ts), please add at least one test with a campaignId that contains reserved characters (e.g. spaces or /) and assert the path segments are properly encoded.

Example:

it('should encode campaignId with special characters in the URL', () => {
  const specialPayload = {
    interactionId: 'interaction-123',
    campaignId: 'My Campaign/Test',
  };
  const dialer = aqmDialer(fakeAqm as any);
  const config = dialer.acceptPreviewContact({ data: specialPayload }) as any;
  expect(config.url).toBe(
    `/v1/dialer/campaign/${encodeURIComponent('My Campaign/Test')}/preview-task/interaction-123/accept`
  );
});

removed this alert because it was annoying and the log is enough to show that outdial ani doesnt work.

cleaning up campaign input fields when task ends

added docs to all the functions in here because they were harder to understand w/out context

Do not resolve preview accepts when the reservation just ends

If the backend closes the preview reservation before it ever emits AgentContactAssigned—for example because the customer is unavailable—this bind still resolves the request as a success because ContactEnded is included in notifSuccess. cc.acceptPreviewContact() then records a success metric and returns to the caller even though no outbound conversation was established, so clients cannot distinguish an immediate failure from a real accept.

Useful? React with 👍 / 👎.

Auto-answer accepted preview calls for browser agents

In Browser/WebRTC mode, this path only rekeys the preview task and emits task:assigned; unlike the AGENT_OFFER_CONTACT/AGENT_OFFER_CONSULT handlers it never calls handleAutoAnswer(task), and the reservation task was created with isAutoAnswering: false. Because Task.accept() is the only code path that invokes answerCall(), accepting a preview contact still requires a second manual task.accept() after the incoming call event, so the new one-click preview flow will not actually connect audio for browser agents.

Useful? React with 👍 / 👎.

this timeout value is consistent with agent desktop: https://sqbu-github.cisco.com/CBABU/wxcc-desktop/blob/main/packages/agentx-services/src/services/aqm/aqm-service-dialer.ts#L82

Prevent preview reservation tasks from exposing a broken accept() path

This emits an ordinary Task instance for AgentOfferCampaignReservation, but Task.accept() never calls dialer.acceptPreviewContact(): for browser telephony it only answers an already-existing WebRTC call, and for non-browser telephony it resolves without sending any AQM request (packages/@webex/contact-center/src/services/task/index.ts:336-375). Any client that reuses its existing task.accept() handler for offered tasks will therefore silently fail to accept preview contacts even though the SDK handed it an ITask.

Useful? React with 👍 / 👎.

Avoid tearing down the active browser call for preview cleanup

Creating preview reservations as normal telephony Tasks means their terminal events will later flow through handleTaskCleanup(), which unconditionally calls webCallingService.cleanUpCall() for any browser telephony task (packages/@webex/contact-center/src/services/task/TaskManager.ts:723-730). In browser/WebRTC mode, an unaccepted preview reservation never owns a call, so if it expires or is rejected while the agent is already on another call this cleanup will drop the unrelated active call.

Useful? React with 👍 / 👎.

I think it would make more sense to put this after the following if statement.

Currently if either value is missing, the payload will be logged here and in the warning a moment later which feels unnecessary

Clean up preview tasks on accept-failure events

acceptPreviewContact() now rejects on the dedicated CampaignPreviewAcceptFailed websocket event, but TaskManager.registerTaskListeners() never handles that new event (unlike AGENT_CONTACT_ASSIGN_FAILED for normal accepts). If the backend reports a preview-accept failure without a follow-up ContactEnded, the reservation task stays in taskCollection and never emits a task-level failure/end signal, so agents can be left with a stale preview reservation after an accept error.

Useful? React with 👍 / 👎.

Avoid exposing decline() on preview reservations

This creates a normal Task instance for AgentOfferCampaignReservation, which means callers also get the standard task.decline() API. Task.decline() only hangs up the current WebRTC call in services/task/index.ts and never sends any preview skip/remove request, so for a preview reservation (where no call exists yet) clients that reuse their usual “decline offered task” handler cannot dismiss the reservation and will leave it active server-side.

Useful? React with 👍 / 👎.

can we only have the docs changes, not code changes. this file exact replica of agentdesktop code base. to have parity lets keep it as it is

same here. please revert the code changes