Files
textbee/web/lib/utils/errorHandler.ts
isra el 3e4597294c refactor: turn on strict TypeScript and fix the 63 errors it found
My earlier estimate of 34 errors was wrong, and the reason is worth
recording: tsconfig carried "strictNullChecks": false as a duplicate key
AFTER the strict flag, and an explicit option beats the strict umbrella
even when --strict is passed on the CLI. So the measurement that produced
34 had silently excluded every null-safety error. The real number was 63.
Both duplicate keys are gone; strict: true now stands alone.

Most were implicit-any, but strict caught several genuine type lies:

- SendSmsPayload.deviceId and WebhookData._id were optional while both
  are interpolated into request paths, so an absent value would have hit
  /gateway/devices/undefined/send-sms or PATCH /webhooks/undefined.
- webhook-table's deviceName was typed string while buildDeviceLabel
  returns string | string[] and the Device cell already renders the
  array case. The type never described what the code produced.
- webhooks-section read `webhooks?.data?.length > 0`, comparing
  undefined against 0 while the query was still in flight.
- app-header declared a non-null Session while its own body guarded with
  session?.user throughout. Making the type honest surfaced four
  genuinely unguarded accesses.
- api-keys kept a local ApiKeyRow duplicating the shared ApiKey type, so
  the list callback annotated rows as one type while the hook returned
  the other. ApiKeyRow is now an alias and the two extra fields moved
  onto ApiKey.
- The notifications envelope typed its rows as unknown[], so the
  deliveries table's row type went entirely unchecked. Now a real
  WebhookNotification type.

The react-hook-form cluster (20 of the 63) was one root cause: zod's
.default() makes the input and output types differ, so z.infer (the
output) is not what the resolver takes. Fixed by typing the forms with
z.input and z.output separately, which changes nothing at runtime.

Also bumped target es5 to ES2017, which fixes the Set-iteration error
that made tsc --noEmit fail before any of this. Next compiles browser
output via SWC and its own browserslist, so bundle targeting is
unaffected. Added @types/papaparse and @types/react-syntax-highlighter,
and a typecheck script, since next build does not check test files.

No @ts-expect-error and no new any were used.

Verified: typecheck clean, build clean, 0 lint errors (21 warnings,
unchanged), 155 unit tests, 78 e2e.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-19 04:19:35 +03:00

98 lines
2.5 KiB
TypeScript

import { AxiosError } from 'axios'
export interface RateLimitErrorData {
message: string
hasReachedLimit: boolean
dailyLimit?: number
dailyRemaining?: number
monthlyRemaining?: number
bulkSendLimit?: number
monthlyLimit?: number
}
export interface FormattedError {
message: string
isRateLimit: boolean
rateLimitData?: RateLimitErrorData
}
/**
* Formats axios errors into user-friendly messages
* Special handling for 429 (rate limit) errors
*/
export function formatError(error: unknown): FormattedError {
if (!error) {
return {
message: 'An unexpected error occurred. Please try again.',
isRateLimit: false,
}
}
// Check if it's an axios error
const axiosError = error as AxiosError
if (axiosError.response) {
const status = axiosError.response.status
const data = axiosError.response.data as any
// Handle 429 rate limit errors
if (status === 429) {
const rateLimitData: RateLimitErrorData = {
message: data?.message || 'Rate limit reached',
hasReachedLimit: data?.hasReachedLimit ?? true,
dailyLimit: data?.dailyLimit,
dailyRemaining: data?.dailyRemaining,
monthlyRemaining: data?.monthlyRemaining,
bulkSendLimit: data?.bulkSendLimit,
monthlyLimit: data?.monthlyLimit,
}
return {
message: rateLimitData.message,
isRateLimit: true,
rateLimitData,
}
}
// For other HTTP errors, use the message from the response
if (data?.message) {
return {
message: data.message,
isRateLimit: false,
}
}
}
// For non-axios errors or errors without a response
if (error instanceof Error) {
return {
message: error.message || 'An unexpected error occurred. Please try again.',
isRateLimit: false,
}
}
return {
message: 'An unexpected error occurred. Please try again.',
isRateLimit: false,
}
}
/**
* The `message` an API error carried, or undefined if it had none.
*
* Distinct from formatError, which always substitutes a generic message.
* Use this where the caller has its own fallback copy worth preserving, and
* needs to know whether the server actually said anything.
*/
export function apiErrorMessage(error: unknown): string | undefined {
const data = (error as AxiosError<{ message?: string }>)?.response?.data
return data?.message
}
/**
* Checks if an error is a rate limit (429) error
*/
export function isRateLimitError(error: unknown): boolean {
const formatted = formatError(error)
return formatted.isRateLimit
}