Глобальный ValidationPipe настроен с transform/whitelist без exceptionFactory. Стандартный Nest validation response содержит message как массив строк. HttpExceptionFilter приводит этот массив к ValidationError[] и читает constraints/property: сведения о полях теряются.
Проблема найдена статической сверкой 14.09.2026 и уже отмечена в docs/architecture/http-api.md. Полный HTTP-сценарий в рамках сверки не запускался — воспроизвести его первым шагом.
Ожидаемое поведение
Для невалидных полей HTTP-ответ содержит статус 400, Content-Type application/problem+json, code VALIDATION_ERROR и непустые errors с корректными pointer/detail по действующему контракту. В ответ не попадают значения пароля/токена, DTO target, stack или внутренние ошибки.
Как воспроизвести
В изолированной HTTP suite создать приложение через штатный configureApp и отправить невалидный запрос к существующему DTO endpoint (например, регистрацию с некорректным email). Проверить реальные status, headers и body после ValidationPipe и HttpExceptionFilter. Не подменять это прямым вызовом фильтра с вручную сконструированным ValidationError[].
Критерии готовности
HTTP regression test воспроизводит потерю деталей на текущей реализации.
Форматы выхода ValidationPipe и входа фильтра согласованы у общего владельца; одинаково исправлены все использующие этот путь endpoints.
Проверены pointer/detail для реальных невалидных полей; вложенные поля учитываются, если входят в существующий DTO-контракт.
Сохранены transform/whitelist, status/code/content-type, безопасная обработка non-validation ошибок и отсутствие чувствительных данных в ответе.
Проходят targeted HTTP regression, backend verify и применимые HTTP/SQLite checks; при изменении wire schema выполнен contract check.
После доказательства исправления обновлено известное расхождение в docs/architecture/http-api.md; generated OpenAPI types не исправляются вручную.
Исправление существующего error contract, без нового формата ошибок и стороннего рефакторинга. Тестовые запросы и данные вымышленные.
## Проблема
Глобальный ValidationPipe настроен с transform/whitelist без exceptionFactory. Стандартный Nest validation response содержит message как массив строк. HttpExceptionFilter приводит этот массив к ValidationError[] и читает constraints/property: сведения о полях теряются.
Проблема найдена статической сверкой 14.09.2026 и уже отмечена в docs/architecture/http-api.md. Полный HTTP-сценарий в рамках сверки не запускался — воспроизвести его первым шагом.
## Ожидаемое поведение
Для невалидных полей HTTP-ответ содержит статус 400, Content-Type application/problem+json, code VALIDATION_ERROR и непустые errors с корректными pointer/detail по действующему контракту. В ответ не попадают значения пароля/токена, DTO target, stack или внутренние ошибки.
## Как воспроизвести
В изолированной HTTP suite создать приложение через штатный configureApp и отправить невалидный запрос к существующему DTO endpoint (например, регистрацию с некорректным email). Проверить реальные status, headers и body после ValidationPipe и HttpExceptionFilter. Не подменять это прямым вызовом фильтра с вручную сконструированным ValidationError[].
## Критерии готовности
- [ ] HTTP regression test воспроизводит потерю деталей на текущей реализации.
- [ ] Форматы выхода ValidationPipe и входа фильтра согласованы у общего владельца; одинаково исправлены все использующие этот путь endpoints.
- [ ] Проверены pointer/detail для реальных невалидных полей; вложенные поля учитываются, если входят в существующий DTO-контракт.
- [ ] Сохранены transform/whitelist, status/code/content-type, безопасная обработка non-validation ошибок и отсутствие чувствительных данных в ответе.
- [ ] Проходят targeted HTTP regression, backend verify и применимые HTTP/SQLite checks; при изменении wire schema выполнен contract check.
- [ ] После доказательства исправления обновлено известное расхождение в docs/architecture/http-api.md; generated OpenAPI types не исправляются вручную.
## Основание
- [ValidationPipe configuration](https://git.personal.ksv741.ru/WealthLedger/backend/src/commit/d4fc28cbbf0bb76a8c11a68f09bbe41151067d88/src/main.ts#L28)
- [HttpExceptionFilter](https://git.personal.ksv741.ru/WealthLedger/backend/src/commit/d4fc28cbbf0bb76a8c11a68f09bbe41151067d88/src/common/filters/http-exception.filter.ts#L70)
- [HTTP contract и известное расхождение](https://git.personal.ksv741.ru/WealthLedger/docs/src/commit/9b19a5cf4df5116c5f603f7189751d37ae9f0ffd/architecture/http-api.md)
- [Согласованные требования ошибок](https://git.personal.ksv741.ru/WealthLedger/specs/src/commit/50658ea8be85568995cc2b71568f9779452424b6/openspec/specs/user-authentication/spec.md)
## Границы
Исправление существующего error contract, без нового формата ошибок и стороннего рефакторинга. Тестовые запросы и данные вымышленные.
Повторная проверка перед релизом 07.10.2026 показала, что дефект уже устранён в develop (a7619d5): configureApp передаёт структурированные ValidationError[] через exceptionFactory, фильтр строит escaped JSON Pointer рекурсивно, а test/app.e2e-spec.ts, test/bank-cards.e2e-spec.ts и test/tbank-screen-sync.e2e-spec.ts проверяют реальные HTTP-ответы 400 application/problem+json с VALIDATION_ERROR, pointer/detail и без synthetic secret. Локально npm run verify и полный npm run test:e2e прошли. Устаревшее примечание docs актуализировано локально; issue можно закрыть после принятия связанного docs commit.
Повторная проверка перед релизом 07.10.2026 показала, что дефект уже устранён в `develop` (`a7619d5`): `configureApp` передаёт структурированные `ValidationError[]` через `exceptionFactory`, фильтр строит escaped JSON Pointer рекурсивно, а `test/app.e2e-spec.ts`, `test/bank-cards.e2e-spec.ts` и `test/tbank-screen-sync.e2e-spec.ts` проверяют реальные HTTP-ответы `400 application/problem+json` с `VALIDATION_ERROR`, `pointer/detail` и без synthetic secret. Локально `npm run verify` и полный `npm run test:e2e` прошли. Устаревшее примечание docs актуализировано локально; issue можно закрыть после принятия связанного docs commit.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Проблема
Глобальный ValidationPipe настроен с transform/whitelist без exceptionFactory. Стандартный Nest validation response содержит message как массив строк. HttpExceptionFilter приводит этот массив к ValidationError[] и читает constraints/property: сведения о полях теряются.
Проблема найдена статической сверкой 14.09.2026 и уже отмечена в docs/architecture/http-api.md. Полный HTTP-сценарий в рамках сверки не запускался — воспроизвести его первым шагом.
Ожидаемое поведение
Для невалидных полей HTTP-ответ содержит статус 400, Content-Type application/problem+json, code VALIDATION_ERROR и непустые errors с корректными pointer/detail по действующему контракту. В ответ не попадают значения пароля/токена, DTO target, stack или внутренние ошибки.
Как воспроизвести
В изолированной HTTP suite создать приложение через штатный configureApp и отправить невалидный запрос к существующему DTO endpoint (например, регистрацию с некорректным email). Проверить реальные status, headers и body после ValidationPipe и HttpExceptionFilter. Не подменять это прямым вызовом фильтра с вручную сконструированным ValidationError[].
Критерии готовности
Основание
Границы
Исправление существующего error contract, без нового формата ошибок и стороннего рефакторинга. Тестовые запросы и данные вымышленные.
Повторная проверка перед релизом 07.10.2026 показала, что дефект уже устранён в
develop(a7619d5):configureAppпередаёт структурированныеValidationError[]черезexceptionFactory, фильтр строит escaped JSON Pointer рекурсивно, аtest/app.e2e-spec.ts,test/bank-cards.e2e-spec.tsиtest/tbank-screen-sync.e2e-spec.tsпроверяют реальные HTTP-ответы400 application/problem+jsonсVALIDATION_ERROR,pointer/detailи без synthetic secret. Локальноnpm run verifyи полныйnpm run test:e2eпрошли. Устаревшее примечание docs актуализировано локально; issue можно закрыть после принятия связанного docs commit.