Comments 1
RestClient очень разочаровывает. Для справки, Kotlin 2.3.20 -> Java 25, VT + coroutines (очень местами, редко, но есть) Spring Boot 4.0.4 (ironic).
Управление таймаутами - будь добр использовать JdkClientHttpRequestFactory, возвращаемую от нативного HttpClient в bean-config'е, другие варианты могут сулить нежелаемым поведением (как видно по стэку мы тут стараемся не блокировать ничего, а если и использовать какой-то из видов lock'ов, то без пина VT)
Интерцепция риквеста - танец костылей из цирка. Добавить какой-то заголовок более-менее удобно, но на этом всё, ибо, если мы доходим до самого сетевого запроса и не падает, то execution.execute() всегда проходит по happy-path и тут начинаются проблемы, ибо обработка ошибок.
Изначально отлавливаемое исключение неинформативно, стэк-трейс худо-бедно полезен, но что именно упало - логай сам. Ни путь, ни глагол, ни тело запроса, ни хэдеры - ничего этого не будет в исключении, если быть точнее, то ничего от запроса не будет в исключении. И если с телом запроса еще проблем нет, то вот с хэдерами, которые прописываются интерцепторами начинаются проблемы, ибо залогировать их нормально достаточно сложно, если вообще возможно. Я предвижу, что хэдеры это чувствительная информация, потому так, но я и не собираюсь их возвращать в доменном исключении, я собираюсь их залогировать, чтобы увидеть, а что там реально сгенерировалось и нет ли в этом ошибки, логи будут высвечиваться в stderr и если у кого-то есть доступ до туда или до Grafana из тех, у кого его быть не должно, то мои логи - меньшая из проблем. С другой стороны передача X-User-Id в заголовке, в котором есть условный userEmail в чистом виде, почему-то чувствительным не является, как и идентификация в теле запроса. В любом случае, можно попытаться решить через MDC, но это переусложненного решение и нужно держать в голове ту разницу, между тем как работают MDC и keyValue() в LogStash. Можно попытаться решить телеметрией, но OpenTelemetry по соображениям безопасности не отслеживает headers и requestBody, будь добр дописывать Http-инструментацию сам.
Извините, накипело.
В общем-то это всё работает хорошо, ровно до момента ошибки и необходимости прозрачности в поддержке, а потом мрак.
P. S. Отдельно улыбнуло, что для борьбы с NPE автор решает использовать Kotlin, ничего против не имею, но сразу вспоминается JEP draft: Null-Restricted and Nullable Types (https://openjdk.org/jeps/8303099), который лежит мертвым уже пол года, зато мы добавляем pattern-matching. А воз, как говорится, и ныне там.
HttpClient в Spring 7: замена FeignClient или нет?