Risk Level
HIGH
File
core/src/utils/error-mapper.ts
Findings
- Line 34:
mapError(error: any): BaseError — the primary public entry point accepts any; callers pass unchecked values
- Line 38:
return new (error.constructor as any)(...) — constructor accessed via as any to clone errors
- Line 69:
const err: any = error — variable re-assigned to any to access dynamic properties
- Line 111:
protected mapByStatusCode(status: number, message: string, data: any, response?: any): BaseError — two any params: data and response
- Line 142:
protected mapBadRequestError(message: string, data: any): BadRequest — data untyped
- Line 178:
protected mapNotFoundError(message: string, data: any): NotFound — data untyped
- Line 206:
protected mapRateLimitError(message: string, response: any): RateLimitExceeded — response untyped
- Line 217:
protected extractErrorMessage(error: any): string — extractor accepts any
- Line 288:
const err: any = error — second any variable re-assignment
- Line 318:
protected extractFromData(data: any): string | undefined — extractor accepts any
Impact
mapError(error: any): BaseError is the central error normalization function used across all exchange adapters — because it accepts any, callers never need to narrow errors before passing them in, which perpetuates catch (error: any) patterns throughout the codebase
error.constructor as any to clone errors could silently break if the error constructor signature changes
- All five protected helper methods (
mapByStatusCode, mapBadRequestError, mapNotFoundError, mapRateLimitError, extractFromData) accept any data — subclasses implementing these cannot rely on TypeScript to verify the data shape
Suggested Fix
- Change
mapError(error: unknown): BaseError — force callers to pass unknown and narrow inside
- Define
HttpErrorData (or use unknown) for the data and response params in the protected helpers; add type guards before accessing fields
- Replace
const err: any = error with explicit narrowing: if (error instanceof Error) { ... } pattern
- Replace
error.constructor as any with a constructor type: new (...args: unknown[]) => Error
Found by automated any type audit
Risk Level
HIGH
File
core/src/utils/error-mapper.tsFindings
mapError(error: any): BaseError— the primary public entry point acceptsany; callers pass unchecked valuesreturn new (error.constructor as any)(...)— constructor accessed viaas anyto clone errorsconst err: any = error— variable re-assigned toanyto access dynamic propertiesprotected mapByStatusCode(status: number, message: string, data: any, response?: any): BaseError— twoanyparams:dataandresponseprotected mapBadRequestError(message: string, data: any): BadRequest—datauntypedprotected mapNotFoundError(message: string, data: any): NotFound—datauntypedprotected mapRateLimitError(message: string, response: any): RateLimitExceeded—responseuntypedprotected extractErrorMessage(error: any): string— extractor acceptsanyconst err: any = error— secondanyvariable re-assignmentprotected extractFromData(data: any): string | undefined— extractor acceptsanyImpact
mapError(error: any): BaseErroris the central error normalization function used across all exchange adapters — because it acceptsany, callers never need to narrow errors before passing them in, which perpetuatescatch (error: any)patterns throughout the codebaseerror.constructor as anyto clone errors could silently break if the error constructor signature changesmapByStatusCode,mapBadRequestError,mapNotFoundError,mapRateLimitError,extractFromData) acceptanydata — subclasses implementing these cannot rely on TypeScript to verify the data shapeSuggested Fix
mapError(error: unknown): BaseError— force callers to passunknownand narrow insideHttpErrorData(or useunknown) for thedataandresponseparams in the protected helpers; add type guards before accessing fieldsconst err: any = errorwith explicit narrowing:if (error instanceof Error) { ... }patternerror.constructor as anywith a constructor type:new (...args: unknown[]) => ErrorFound by automated any type audit