Refine THProviderErrorMapper error mapping and MDC tests

[karle0wne]

существующие тесты пропустили
для ускорения дебага // @test todo

Details

⛬ Как сейчас работает THProviderErrorMapper (по шагам)

1. Что он делает в целом

THProviderErrorMapper — это центральный «переводчик» между внутренними исключениями/метаданными Woody и тем, что уходит
наружу: либо как HTTP-ответ (через THResponseInfo), либо как WErrorDefinition, который дальше разбирают слушатели и клиенты.

──────────────────────────────────────────

2. Когда есть готовый WErrorDefinition (например, в метаданных)

getResponseInfo(ContextSpan span)

1. Смотрим WErrorDefinition в метаданных спана (ERROR_DEFINITION).
2. Нет определения → отдадим «200, всё хорошо».
3. Есть определение → по типу и generationSource решаем HTTP-статус:
   • BUSINESS_ERROR → всегда 200, errClass = "business_error".
   • PROVIDER_ERROR:
   • Если это ошибка ещё на входе (запрос не успели обработать) → статус 4xx в зависимости от TErrorType/метаданных:
   • PROTOCOL → 400
   • TRANSPORT → mapTransportErrorStatus (405 / 415 / 400)
   • Остальное → 400
   • Если это уже в ответе → 500, если генерили сами (internal), или 502, если проксировали внешний сбой.
   • UNAVAILABLE_RESULT → 503 (internal) или 502 (external).
   • UNDEFINED_RESULT → 504 (internal) или 502 (external).
   • UNEXPECTED_ERROR → 500 (internal) или 502 (external).
4. errReason берётся из WErrorDefinition.
5. Если в спане лежит THRequestInterceptionException (например, перехватчик не пропустил запрос) — статус и тип ошибки
   перебиваются на транспортный (400/405/415), потому что до сервиса мы не дошли.
6. Результат возвращаем в виде THResponseInfo.

──────────────────────────────────────────

3. Когда нужно построить WErrorDefinition по HTTP-ответу

createErrorDefinition(THResponseInfo info, Supplier invalidErrClass)

1. Смотрим статус:
   • 200 + errClass=business_error → создаём WErrorDefinition:
   • generationSource = EXTERNAL
   • errorType = BUSINESS_ERROR
   • errorSource = INTERNAL (ошибка бизнес-логики сервиса)
   • 503 → UNAVAILABLE_RESULT, generationSource = EXTERNAL, errorSource = INTERNAL.
   • 504 → UNDEFINED_RESULT, generationSource = EXTERNAL, errorSource = INTERNAL.
   • 502 → UNEXPECTED_ERROR (если не указано лучше), и обе стороны EXTERNAL. Если внутри 502 всё-таки сидит business_error,
   вызываем invalidErrClass.get() — сигнал, что кто-то неправильно вернул бизнес-ошибку через 502.
   • Любой другой статус (например, 400/500) → UNEXPECTED_ERROR, generationSource = EXTERNAL, errorSource = INTERNAL.
2. Сообщение нормализуем:
   • Для 4xx ставим стандартные текстовые Reason-Phrase (Bad Request, Method Not Allowed, т. п.).
   • Если у 5xx пустой errClass и есть errReason, чтобы не светить 500 без содержания, понижаем сообщение до «Bad Request».
   • Если совсем ничего нет, используем дефолтный Reason-Phrase по статусу.
3. Возвращаем новый WErrorDefinition (или null, если статус 200 без бизнес-ошибки — там реально «всё ок»).

──────────────────────────────────────────

4. Когда есть исключение

mapToDef(Throwable t, ContextSpan span)

1. Если исключение — thrift-ошибка (или транспорт Woody), пытаемся достать уже готовое определение из метаданных (чтобы не
   переписывать то, что поставили расширения/перехватчики). Если есть и исключение не THRequestInterceptionException, берём
   его.
2. Иначе строим новое через createDefFromWrappedError(metadata, err):
   • TApplicationException.PROTOCOL_ERROR → TErrorType.PROTOCOL, причина «thrift protocol error».
   • TApplicationException.UNKNOWN_METHOD → UNKNOWN_CALL, причина «unknown method: <имя>».
   • Остальные TApplicationException → UNKNOWN, причина «unknown provider error: …».
   • TProtocolException → PROTOCOL, причина «thrift protocol error».
   • TTransportException → TRANSPORT, причина «thrift transport error».
   • Если в метаданных статус 4xx → считаем, что это внешняя ошибка (generationSource = EXTERNAL, errorSource = EXTERNAL).
   • Если статуса нет, но сообщение похоже на пустой ответ HTTP (HTTP response code: …, «No more data available.») → тоже
   внешняя.
   • THRequestInterceptionException (до сервиса не дошли) → TRANSPORT, подставляем подтип (BAD_HEADER, BAD_CONTENT_TYPE и т.
   д.), генератором считаем:
   • клиентский контекст → generationSource = INTERNAL (мы сами забраковали свой outbound запрос);
   • серверный контекст → EXTERNAL (пришёл мусор извне).
   • errorSource ставим равным generationSource, а причину формируем читаемо («bad header: X-Test», «content type
   wrong/missing» и т. д.).
   • Любое другое исключение → UNKNOWN, причина «internal thrift application error».
3. Новая дефиниция всегда получает errorType = PROVIDER_ERROR, errorSource соответствует определённому generationSource,
   errorReason/errorMessage — по исключению.
4. В метаданные записываем TH_ERROR_TYPE (и при необходимости TH_ERROR_SUBTYPE), чтобы getResponseInfo понимал, как
   обрабатывать.

──────────────────────────────────────────

5. Вспомогательные моменты
   • mapTransportErrorStatus переводит транспортные ошибки в коды: BAD_REQUEST_TYPE → 405, BAD_CONTENT_TYPE → 415, остальные →
   400.
   • isNoPayloadTransportError ловит текстовые сообщения TTransportException без полезной нагрузки («HTTP Response code: …»,
   «No more data available.») и помечает их как внешние.
   • Если перехватчик (ContextUtils.getInterceptionError) уже прервал запрос, getResponseInfo обязательно отдаёт 4xx,
   независимо от дальнейших событий.

──────────────────────────────────────────

6. Что изменилось (кратко)
   • Внешний шум (apстрим/сетевые ошибки) теперь показывается как generationSource=EXTERNAL, errorSource=EXTERNAL.
   • Настоящие ошибки сервиса (бизнес, undefined/unavailable результат, внутренние 500) — generationSource=EXTERNAL, но
   errorSource=INTERNAL, что отражает, что сбой произошёл у нас.
   • Сообщения по 4xx/5xx нормализованы, чтобы клиент видел понятные Reason-Phrase.
   • Тесты (THProviderErrorMapperTest, MDCLogTest, TestClientEventHandling, TestNginxError и пр.) покрывают эти комбинации и
   подтверждают согласованность.

В итоге любой внешний потребитель по WErrorDefinition и HTTP-статусу точно понимает, кто виноват (мы или апстрим), и что за
проблема случилась.