Logical API errors throw stable codes so users see translated messages instead of a generic bad request. Co-authored-by: Cursor <cursoragent@cursor.com>
1.4 KiB
1.4 KiB
name, description
| name | description |
|---|---|
| dyolink-api-errors | Adds or migrates Dyolink API error codes with frontend translations. Use when adding backend validation errors, permission errors, or migrating catch blocks to getUserFacingError. |
Dyolink API errors
Backend
- Add code to
ErrorCodeinbackend/src/common/errors/error-codes.ts. - Throw with
AppException:
throw new AppException(ErrorCode.MY_CODE, HttpStatus.BAD_REQUEST);
- DTOs: always
{ message: ErrorCode.X }on class-validator decorators (do not rely on constraint-key fallbacks — e.g.@Matchesis not always a mobile number). - Do not throw Nest
BadRequestException('English…')— unmapped Nest exceptions fall back to HTTP status only (BAD_REQUEST,AUTH_UNAUTHORIZED, …). - Wall-clock rules (working hours, weekday): pass the client IANA
timeZoneand usezoned-civil-time.ts. NeverDate#getHours()/getDay()on the UTC server.
Frontend
- Add key under
"errors"inen.json,fa.json,nl.json(key = error code string). - In components:
const tErrors = useTranslations('errors');
// ...
catch (err: unknown) {
toast.showError(getUserFacingError(err, tErrors, t('fallbackKey')));
}
- Do not use
err.messageor(err as Error).messagefor user display.
Axios shape
Parsed in lib/api/client — expects { success: false, error: { code, details? } }.
See rule: .cursor/rules/api-errors-i18n.mdc