[danielpeng1]

Eliminate the DEP0169 url.parse() deprecation warning emitted by BitGo Express on proxied requests with query parameters.

• createAPIPath in modules/express/src/clientRoutes.ts extracts the query string by slicing req.url from the first ? up to any #, replacing the legacy url.parse() call that triggered DEP0169.
• The slice preserves query bytes exactly as the client sent them and matches legacy url.parse().search behavior, including stripping fragments; the unused url import is removed.
• Affects only the catch-all proxy handlers that call createAPIPath (v1 REST passthrough, v2 user, v2 coin-specific); local typed routes and the coin modules' getAddressDetails url.parse calls are unchanged.

Tests

• modules/express/test/unit/clientRoutes/proxiedQueryStrings.ts runs real requests through the express app and asserts the exact upstream request path via nock: no query, simple query, percent-encoded values (%20, %27, %2B), +, repeated keys, empty value, bare ?, and v2 user and v2 coin paths forwarded byte-for-byte.

Ticket: WCN-4315

[linear-code]

WCN-4315

WCN-4316

[github-actions]

⚠️ Compatibility checks are failing on Node.js 27-nightly (experimental, non-blocking). This does not block merge, but it signals an incompatibility to fix before this release becomes supported.

View run

[claude]

Claude Code Review

This repository is configured for manual code reviews. Comment @claude review for a one-time review, or @claude review always to subscribe this PR to a review on every future push.

_{Tip: disable this comment in your organization's Code Review settings.}

[danielpeng1]

@claude review

[claude]

Nothing blocking. The comments below are optional suggestions. There is no need to push a fix for them before merging.

[claude]

🟡 (optional) Operators running Express from source or the Docker image will most likely still see the DEP0169 warning on authenticated proxied requests, so the PR's goal is not met. The same request still reaches legacy url.parse in setRequestQueryString (modules/sdk-api/src/api.ts:212) and calculateHMACSubject (modules/sdk-hmac/src/hmac.ts:45). Fix: remove url.parse along the whole proxied-request path, which means changing sdk-api and sdk-hmac. That is larger than this change, so either do it or narrow the PR's claim. Node prints DEP0169 only once per process, so moving the first call elsewhere does not remove the warning.

Why this was flagged

Trigger: an authenticated client (access token set) sends a proxied GET with a query, e.g. /api/v2/tbtc/wallet?allTokens=true, through handleV2CoinSpecificREST -> createAPIPath -> redirectRequest. In bitgoAPI.ts:599 _sendRequestWithHmac calls setRequestQueryString(req), which runs urlLib.parse(req.url) at api.ts:212. It then calls calculateRequestHeaders, which reaches urlLib.parse(urlPath) at sdk-hmac/src/hmac.ts:45, and verifyResponse parses the same way. Node only raises DEP0169 when the caller is not inside node_modules. The Dockerfile copies sdk-api and sdk-hmac to /var/modules/... (lines 59, 61), and the monorepo runs them from modules/..., which are the same setups where clientRoutes.ts emitted the warning on base. The warning is deduplicated per process, so operators still get exactly one DEP0169, just from a different file. The new unit test only checks upstream paths and never checks that the warning is gone.

Verification: Severity: nit. The warning was already there on the base. _sendRequestWithHmac calls setRequestQueryString(req) at bitgoAPI.ts:599, which always runs urlLib.parse(req.url) (sdk-api/src/api.ts:212). In the Docker image, sdk-api and sdk-hmac live in /var/modules, not node_modules, so these calls count as application code and the warning is still printed.