startCallDeadline
startCallDeadline(
timeoutMs):CallDeadline
Defined in: packages/core/src/runtime/abortableCall.ts:95
Start a wall-clock budget.
The ordering inside the timer callback is load-bearing. The sentinel is resolved before the
controller is aborted, because aborting first can settle the in-flight call’s promise ahead of
the sentinel — and then Promise.race yields the AbortError instead of CALL_TIMED_OUT.
At the rater that would silently re-file a timeout as a thrown call: the verdict’s
FailClosedCause would become 'threw' rather than 'timeout', moving a gate decision
[[EXT-171]] rules on onto a different arm, with the user-facing sentence changing to match. With
the sentinel resolved first the race is settled before the abort can be observed, so every site
keeps exactly the timeout path it had.
The timer is deliberately not unref’d. It is the budget itself, not a backstop, and an
unref’d budget can be skipped entirely if nothing else is holding the loop — which would make the
timeout path untestable in exactly the conditions it exists for. CallDeadline.dispose is
what stops it outliving the call.
Parameters
Section titled “Parameters”timeoutMs
Section titled “timeoutMs”number
The wall-clock budget in milliseconds.