fix: classify request timeouts distinctly instead of unknown error

[reeshika-h]

Problem

Under retryResponseErrorHandler, an axios client-side timeout (error.code === 'ECONNABORTED') was converted into a plain object literal — { error_message, error_code, errors } — instead of a real Error. That object has no .message, .request, or .response.

APIError.fromAxiosError only classifies errors by checking err.response?.data, then err.request != null && response == null, then err.message. The plain object matches none of those, so it fell through to the final catch-all and surfaced to SDK consumers as:

error_code: 'UNKNOWN_ERROR', status: 0, error_message: 'An unknown error occurred...'

This is indistinguishable from a genuine network-layer failure (DNS resolution failure, connection reset, etc.) — a legitimate 30s request timeout gave consumers zero information that it was, in fact, a timeout.

Confirmed via git blame this was an unintended regression from a well-intentioned change (commit feb5bfb, Jun 2024) that tried to give timeouts a distinct 408/TIMEOUT identity, but never updated fromAxiosError to recognize the shape it produced.

Fix

Throw a real Error with .message set to the existing timeout message and .code set to the TIMEOUT constant, instead of a plain object literal. No changes needed in api-error.ts — its existing err.message branch already produces a correct, distinct APIError once the thrown value is a proper Error.

Also removed the /* eslint-disable @typescript-eslint/no-throw-literal */ at the top of the file — nothing throws a literal anymore.

Scope

This fix only corrects error classification. It does not change whether a timed-out request is retried (unchanged: ECONNABORTED is not retried unless a custom retryCondition matches it) and does not touch connection pooling/keepAlive defaults. Those are tracked separately as follow-up SDK-side improvements under the same ticket, to be reviewed and shipped independently given they change default behavior for all consumers.

Tests

• Added an integration-style test that runs a real ECONNABORTED error through the actual retryResponseErrorHandler → APIError.fromAxiosError pipeline (no mocking either side) — reproduces the reported bug before the fix (error_code: 'UNKNOWN_ERROR' instead of 408).
• Updated the one existing unit test that asserted the old, broken plain-object shape.
• Full suite green (145/146; the one unrelated failure is a pre-existing stale-dist-build check, confirmed via git stash to predate this change).
• 100% statement/line/function coverage, ~97% branch coverage on both touched files.

Test plan

• Unit tests pass (npm test)
• Lint passes with no new warnings/errors
• Reviewer confirms the classification change doesn't surprise any downstream consumer relying on the old plain-object shape (none found in this repo's own call sites)

[github-actions]

🔒 Security Scan Results

ℹ️ Note: Only vulnerabilities with available fixes (upgrades or patches) are counted toward thresholds.

Check Type	Count (with fixes)	Without fixes	Threshold	Result
🔴 Critical Severity	0	0	10	✅ Passed
🟠 High Severity	0	0	25	✅ Passed
🟡 Medium Severity	0	0	500	✅ Passed
🔵 Low Severity	0	0	1000	✅ Passed

⏱️ SLA Breach Summary

✅ No SLA breaches detected. All vulnerabilities are within acceptable time thresholds.

Severity	Breaches (with fixes)	Breaches (no fixes)	SLA Threshold (with/no fixes)	Status
🔴 Critical	0	0	15 / 30 days	✅ Passed
🟠 High	0	0	30 / 120 days	✅ Passed
🟡 Medium	0	0	90 / 365 days	✅ Passed
🔵 Low	0	0	180 / 365 days	✅ Passed

✅ BUILD PASSED - All security checks passed