Исправление gRPC deadline для T-Bank портфеля

Контекст

При запросе брокерского портфеля T-Bank бэкенд дополнительно обогащает позиции через InstrumentsService/GetInstrumentBy. Для портфеля с несколькими позициями эти запросы запускаются пачкой, но TBankClientService пропускает реальные gRPC-вызовы через локальный PQueue rate limiter.

Сейчас deadline создаётся до постановки задачи в очередь. Если вызов ждёт rate limiter, время ожидания съедает T_BANK_REQUEST_TIMEOUT_MS, и gRPC может завершиться мгновенным DEADLINE_EXCEEDED after 0.000/0.001s ещё до сетевого запроса.

Цель

Сделать так, чтобы локальное ожидание в PQueue не расходовало gRPC deadline, а сбой обогащения отдельного инструмента не ломал весь ответ портфеля.

Границы

Не менять публичный API /api/v1/broker/accounts/:accountId/portfolio.
Не менять значения переменных окружения и конфигурацию rate limiter.
Не добавлять retry/backoff в этом исправлении.
Не менять стратегию кеширования инструментов.

Acceptance criteria

TBankClientService.callUnary() создаёт Metadata и deadline непосредственно перед фактическим gRPC-вызовом внутри задачи PQueue.
T_BANK_REQUEST_TIMEOUT_MS измеряет время выполнения upstream gRPC-вызова, а не время ожидания локальной очереди.
Есть regression test, который доказывает, что второй queued-вызов получает deadline после ожидания очереди.
BrokerPortfolioService строит карту инструментов best-effort: ошибка одного GetInstrumentBy не роняет весь портфель.
Есть regression test, который доказывает, что портфель возвращается, если один инструмент не удалось обогатить.

Проверка

Targeted tests: npm run test -w apps/backend -- src/modules/tbank/services/tbank-client.service.spec.ts src/modules/tbank/services/broker-portfolio.service.spec.ts
Full backend tests: npm run test:backend

2.7 KiB Raw Permalink Blame History Unescape Escape