Узел: Запросить контекст при вызове другой лямбда-функцией

Question

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

Моя проблема по этому вопросу : я не знаю, каклегко расширять мои журналы с уникальным идентификатором трассировки, чтобы все журналы, относящиеся к одной транзакции, регистрировались с одинаковым идентификатором.

Чтобы получить представление об одном из процессов:

• lambda #1 использует экспресс и предоставляет API через ApiGateway.В рамках одной «транзакции» он также ставит в очередь некоторые события в SQS.
• lambda #2 регулярно опрашивает очередь и выполняет другую работу.После этого он вызывает lambda #1 напрямую для завершения транзакции.

Итак, весь поток: some other app - Запрос с TraceID -> ApiGateway -> lambda #1 -> SQS -> lambda #2 -> lambda #1.

То, что я делал до сих пор Я использую request-context для отслеживания запросов.Но это просто работает, если вы получили правильный контекст запроса.Поэтому я не могу войти с правильным идентификатором трассировки на lambda #1 после того, как он был вызван на последнем этапе lambda #2 (который отправляет идентификатор трассировки в своем запросе).

Точка вызова для lambda #1 выглядит так:

export function handler(event: any, context: any) {
  if (event.targetAction) {
    switch (event.targetAction as TargetAction) {
      // invocation by lambda #2 will end up here
      // we got no request context for express
      case TargetAction.FINISH_TRANSACTION:
        /** do some other work **/
        return;
      default:
      /** **/
    }
  }
  return awsServerlessExpress.proxy(server, event, context);
}

Как мне получить свой идентификатор трассировки в журналах в этом случае?

Другие мысли :

• Я мог бы сделать обходной путь и добавить новый маршрут к lambda #1, а также отправить метод пути и http для моего события, а затем передать его обработчику прокси, чтобы мы оказались на экспресс-маршруте.Похоже, плохое решение.

Я очень рад за любую помощь или мысль по этому поводу, даже если это указывает мне в каком-то совершенно ином направлении.

Редактировать

Сейчас я иду с обходным путем, который работает нормально.Я создал маршрутизатор для внутреннего использования.Вот как выглядит обработчик, если кому-то интересно:

export function handler(event: any, context: any) {
if (event.targetAction) {
  switch (event.targetAction as TargetAction) {
     case TargetAction.UPDATE_TRANSACTION:
        const updateEvent: ExpressProxyEvent = {
           path: '/internal/update-transaction',
           headers: {
              'Content-Type': 'application/json',
              'x-trace-id': event.xtraceId,
              'x-internal-router-secret': Constants.INTERNAL_ROUTER_SECRET
           },
           body: JSON.stringify(event),
           httpMethod: 'POST'
         };
         event = updateEvent;
         break;
      case /** **/
    }
    return awsServerlessExpress.proxy(server, event, context);
}

При этом traceId может быть установлен в промежуточном программном обеспечении запроса при вызове напрямую другой лямбда-функцией (событие также может быть правильно создано вlambda #2, но тогда необходимо знать путь и метод для внутреннего маршрутизатора в lambda #1).

Тем не менее, я все еще заинтересован в независимом решении.