The ws v8 library throws a plain Error('Opening handshake has timed out') with no
.code and name 'Error' when the handshake timeout (JAMBONES_WS_HANDSHAKE_TIMEOUT_MS,
default 1500ms) elapses. BaseRequestor._shouldRetry classified retryable errors only
by .code/.name/.statusCode, so this error matched neither the ct nor rt bucket and was
never retried under the default rp=ct policy — the call failed immediately on the first
attempt, silently bypassing maxReconnects.
Match the handshake-timeout message in the ct bucket so a transient slow WS upgrade
(e.g. a serverless/edge backend cold start) is retried as intended. Adds tape coverage
for both the default-ct retry path and the rp=4xx no-retry path.
_lccTtsTokens silently returned on a missing `id`, leaving the WS client with
no feedback — no tts:tokens-result, no audio, only a server-side info log.
Mirror the existing missing-`tokens` handling and reply with status 'failed' /
reason 'missing id' so callers that omit `id` (e.g. the Python SDK) get an
actionable result.
* fix: fire sip:refer actionHook when the far end BYEs before any NOTIFY
When a REFER is accepted with 202 the verb waits for a NOTIFY carrying the
final status of the referred call, and only fired the actionHook from the
15s timeout callback. If the far end sends BYE straight after the 202 the
call session kills the task, awaitTaskDone() resolves, and exec returned
without ever performing the action.
Perform the action once from exec on every exit path - before the session
tears the requestor down - and de-duplicate it against the final-NOTIFY path.
Fix#1258
Generated by Ora Studio
Vibe coded by ousamabenyounes
Co-Authored-By: Ora Agent <noreply@oratelecom.net>
* fix: keep final_referred_call_status when a BYE races the final NOTIFY (#1580)
A final NOTIFY (status >= 200) whose eventHook round trip is still in flight
when the far end BYEs lost final_referred_call_status on the actionHook: kill()
woke exec(), which memoised the action via _performReferAction({refer_status})
without the final status, so the NOTIFY path's later call carrying it was
deduped away. On main the app received final_referred_call_status here.
Record the final status synchronously in _handleNotify before the eventHook
await, and include it from exec() so the memoised action carries it regardless
of which exit path wins the race. Extract the 200 threshold into a named
constant while touching those lines.
Addresses davehorton's review on #1580.
Generated by Ora Studio
Vibe coded by ousamabenyounes
Co-Authored-By: Ora Agent <noreply@oratelecom.net>
---------
Co-authored-by: Ora Agent <noreply@oratelecom.net>
Co-authored-by: Ben Younes <2910651+ousamabenyounes@users.noreply.github.com>
Ben Younes