feat: add AbortSignal and rename timeout → timeoutMillis in SendRequestOptions

[Copilot]

SendRequestOptions lacked an AbortSignal option, preventing users from passing custom cancellation signals to BaseHttpClient. The timeout field also didn't follow the repo convention of using timeoutMillis.

Changes

• @crawlee/types — SendRequestOptions: renamed timeout → timeoutMillis, added signal?: AbortSignal
• @crawlee/http-client — BaseHttpClient: updated to use timeoutMillis; when both signal and timeoutMillis are provided, combines them via AbortSignal.any()
• @crawlee/basic-crawler, @crawlee/http-crawler, @crawlee/utils — updated all call sites to use timeoutMillis
• test/core/base-http-client.test.ts — added tests covering custom signal propagation, signal + timeoutMillis combination, and timeout-based abort

Usage

const response = await httpClient.sendRequest(request, {
    timeoutMillis: 10_000,
    signal: myAbortController.signal,
});

When both are supplied, the request is aborted on whichever fires first.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>v4: add AbortSignal option to the BaseHttpClient interface</issue_title>
<issue_description>Adding AbortSignal option to the BaseHttpClient interface would allow users to pass their custom signal to the HttpClient (alongside the timeout, which should be renamed to timeoutMillis to follow the best practices in this repo).</issue_description>

<agent_instructions>Make minimal changes to achieve the goal described in the issue. do not add excessive comments (but add TSdocs for public interfaces you add). use conventional commits for commit messages and PR title.</agent_instructions>

Comments on the Issue (you are @copilot in this section)

• Fixes v4: add AbortSignal option to the BaseHttpClient interface #3456

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[Copilot]

Pull request overview

This pull request adds support for custom AbortSignal cancellation to the HTTP client layer and renames the timeout parameter to timeoutMillis to align with the repository's established naming conventions. The changes address the lack of a mechanism for users to pass custom cancellation signals to BaseHttpClient, while also improving consistency across the codebase.

Changes:

• Added signal?: AbortSignal field to SendRequestOptions interface with TSDoc
• Renamed timeout → timeoutMillis in SendRequestOptions to follow the established Millis suffix convention used throughout the codebase
• Implemented AbortSignal.any() to combine custom signals and timeout-based signals, ensuring requests abort on whichever fires first
• Updated all call sites across @crawlee/basic-crawler, @crawlee/http-crawler, and @crawlee/utils to use the new parameter name

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
packages/types/src/http-client.ts	Added signal field and renamed timeout → timeoutMillis in SendRequestOptions interface with documentation
packages/http-client/src/base-http-client.ts	Updated createAbortSignal to accept and combine both signal and timeout; refactored resolveRequestContext to return signal instead of timeout
packages/basic-crawler/src/internals/send-request.ts	Updated to pass both timeoutMillis and signal from override options
packages/http-crawler/src/internals/http-crawler.ts	Updated call site to use timeoutMillis parameter name
packages/utils/src/internals/sitemap.ts	Updated call site to use timeoutMillis parameter name
packages/utils/test/mock-http-client.ts	Updated mock implementation to use timeoutMillis parameter name

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[nikitachapovskii-dev]

Hi, sorry for a late review 🙂
Please check the nits, hope they are useful

[nikitachapovskii-dev]

It seems like the timeout behavior changed with this refactor. Previously, the timeout signal was created inside the redirect loop (per fetch attempt). Now the signal is created once before the loop and reused across all redirects
If I don't miss smth, this can lead to cases, when redirect chains that used to pass (each hop under timeout) may now fail if cumulative time exceeds timeoutMillis.

If this is not expected, we should create the timeout signal per iteration

[barjin]

I would argue that this behaviour is more straightforward (user sets timeoutMillis as a sendRequest param, so they expect the sendRequest call to take up to this time).

I'm not sure how this worked before (it was probably implementation-specific), so this is imo a step forward (in v4 nonetheless, as we can afford breaking changes like this). Wdyt?

[nikitachapovskii-dev]

I think this is a reasonable v4 direction, and I’m okay with keeping it 👍