самый забавный холивар который я видел

Так и корутина рано или поздно свалится в синхронный вызов

интересно, кто там победил

интересно, кто там победил

Господа, позвольте отвлечь вас от насущных проблем и поговорить об абстрактном. Третий день голову мою терзают мысли о том, как бы получше, поэлегантнее да поудобнее прикрутить логи к бэкенду. Да не простые, а с добавлением идентификатора запроса к каждой записи. Вся чудо-поделка пилится на Go, но мне кажется, что это не сильно принципиально.

Вот пришёл запрос, я ему бац! и приделал uuid в контекст используя middleware. То-есть могу из объекта запроса в любой момент получить его идентификатор.
Теперь приходит запрос в handler/обработчик, там всё чинно-гладко. logFooBar(getRequestID(request), "Hello, world, you obosralza")
Теперь обработчик тянется своими ручками в сервис. Вызывает handler.fooBarUsersService.searchForAlkogolik(parseRequestBodyFilter(request)) и дальше пляски идут внутри сервиса.

Вопрос: как мне передать идентификатор внутрь сервиса? Какие есть техники? Можно явно первым аргументом закинуть, можно сделать копию сервиса _для_этого_запроса_ и передать туда идентификатор полем, можно крутануть эту баламуть в контексте каком-нибудь как-нибудь и тягать оттуда (не хочу, звучит как бред).

А сервис потом ещё в репозиторий сходит базу потормошить, да пару запросов с рассылкой спама отправит в sendgrid.

если каждый запрос и не хочешь  минимизипровать проблемы с перфом, то тебе нужны не просто логи, а трейсинг.
смотри jaeger и zipkin например.

ежели хочешь быть вообще на острие последних веяний то сюда
https://opentelemetry.io/

по техникам. техника называется x-request-id, к каждому запросу цепляется хедер с уникальным ид. система телеметрии выделяет этот ид в отдельный тег (setTag в контекте open tracing и open telemetry), где по нему потом запрос благополучно ищется в куче трейсов (считай логов)

если каждый запрос и не хочешь  минимизипровать проблемы с перфом, то тебе нужны не просто логи, а трейсинг.
смотри jaeger и zipkin например.

ежели хочешь быть вообще на острие последних веяний то сюда
https://opentelemetry.io/

по техникам. техника называется x-request-id, к каждому запросу цепляется хедер с уникальным ид. система телеметрии выделяет этот ид в отдельный тег (setTag в контекте open tracing и open telemetry), где по нему потом запрос благополучно ищется в куче трейсов (считай логов)

А вот Навальный учил пайтон

Хедер я и так прицепил, это понятно. Но эта информация существует ровно до момента выхода из обработчика в сервис, где ни реквеста, ни идентификатора нет.

суть в том, что ты должен передавать его насквозь в остальные интеграции. твой сервис делает запрос сам на сонвоание входящего - добавляй этот же ид. причём не важно хттп это или что-то другое, например amqp или kafka, в любом протокле, где есть хедеры ты прокидываешь этот же ид, а остальные системы используют эту же систему телеметрии и единую помойку логов-трейсов.
по итогу по ид входящего запрсоа ты можешь отслеживать всю цепочку взаимодействия на различных сервсиах.

ого, так вот что это за X-Request-ID на прошлой работе были

Да-да, именно это я и пытаюсь сделать. У меня вопрос по деталям реализации - как передать этот идентификатор в коде без лишнего кода.

Да уже первый выбрал, присаживаюсь поудобнее.