Зависающий orderbook

[Dronablo]

Привет!

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

            print('F1')
            channel = grpc.secure_channel('trade-api.finam.ru:443', grpc.ssl_channel_credentials())
            stub = EventsStub(channel)

            print('F2')

            def gen_ob_req(code, board):
                yield SubscriptionRequest(
                    order_book_subscribe_request=OrderBookSubscribeRequest(
                        request_id=''.join(random.choices(string.ascii_uppercase + string.digits, k=12)),
                        security_code=code,
                        security_board=board))

            print('F3')

            req = stub.GetEvents(gen_ob_req(bond_data['secid'], bond_data['primary_boardid']),
                                 metadata=[('x-api-key',
                                            self.account.token)])

            print('F4')

            orderbook_result = None
            for orderbook_result in req:
                if orderbook_result.WhichOneof('payload') == 'order_book':
                    break
                print(orderbook_result.WhichOneof('payload'))
                print(orderbook_result)
            print('F5')

И он в 95% случаев работает хорошо, но иногда отдает такое:

F1
F2
F3
F4
response
response {
  request_id: "OKQ4JA1GFGP3"
  success: true
}

После чего зависает намертво минут на 10, пока не получает grpc RST.

Я понимаю что туда нужно будет просто добавить таймаут, но в целом кажется что это работает не так, как нужно - если он отвечает response.success == true, то хорошо бы ему после этого начать таки слать orderbook.

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

@solyutor @oakio подскажете что-нибудь?

[oakio]

Данный код получения стакана работает и ничего не зависает, значит дело не в сервисе TradeApi:

using Finam.TradeApi.Grpc.V1;
using Finam.TradeApi.Proto.V1;
using Grpc.Core;
using Grpc.Net.Client;

using var channel = GrpcChannel.ForAddress("https://trade-api.finam.ru:443");
Metadata headers = new()
{
    { "X-Api-Key", "...." }
};

var client = new Events.EventsClient(channel);
var stream = client.GetEvents(headers);

var stop = new CancellationTokenSource();
var task = Task.Run(async () =>
{
    IAsyncStreamReader<Event> responseStream = stream.ResponseStream;
    while (await responseStream.MoveNext(stop.Token))
    {
        Event e = responseStream.Current;
        if (e.PayloadCase == Event.PayloadOneofCase.Response)
        {
            ResponseEvent response = e.Response;
            Console.WriteLine($"reqId={response.RequestId}, success={response.Success}");
        }
        else
        {
            Console.WriteLine(e.PayloadCase);
        }
    }
});

await stream.RequestStream.WriteAsync(new SubscriptionRequest
{
    OrderBookSubscribeRequest = new OrderBookSubscribeRequest
    {
        RequestId = "req1",
        SecurityBoard = "TQBR",
        SecurityCode = "VTBR",
    }
});

Console.WriteLine("Press any key to exit...");
Console.ReadKey();
stop.Cancel();
await task;

[Dronablo]

Смотрите:

• Моя цель не в том чтоб сказать "вот вы какие плохие", а в том чтоб помочь сделать сервис немного лучше.
• Как я писал - зависание происходит очень редко. Но точно происходит.
• Если вам это интересно - я могу насобирать request id за пару дней, которые зависли, и принести вам: посмотрите логи.
• Если нет - окей, записываем ответ "а у меня такая же нога - и не болит" как окончательный =).

[oakio]

Да, request Id очень бы пригодился. Я сейчас тоже попробую отловить это зависание.

[Dronablo]

Ну вот OKQ4JA1GFGP3 из первого сообщения - это сегодня утром, где-то между 10 и 10:30 Мск.
Зависание кстати всегда ровно 10 минут - это кажется похоже на линуксовый дефолтный dead connection detection таймаут.
Если я добавляю таймаут к этому вызову (скажем, 10 секунд; в норме все работает мгновенно), то он мне отдает кишочки с вашими внутренними ip и похожим на Golangовский deadline exceeded.

Наберу еще йдишников/выводов таймаута - приложу сюда.

[Dronablo]

Прямо сейчас висит: NF6CEMO8DVZ3

[Dronablo]

Заканчивается этот запрос ровно через 10 минут вот таким:

_MultiThreadedRendezvous: <_MultiThreadedRendezvous of RPC that terminated with:
	status = StatusCode.INTERNAL
	details = "Received RST_STREAM with error code 2"
	debug_error_string = "{"created":"@1681212562.377000000","description":"Error received from peer ipv4:78.41.199.213:443","file":"src/core/lib/surface/call.cc","file_line":1064,"grpc_message":"Received RST_STREAM with error code 2","grpc_status":13}"

[Dronablo]

D0CNODQF4HHI с таймаутом 10 секунд заканчивается таким:

_MultiThreadedRendezvous: <_MultiThreadedRendezvous of RPC that terminated with:
	status = StatusCode.DEADLINE_EXCEEDED
	details = "Deadline Exceeded"
	debug_error_string = "{"created":"@1681213193.256000000","description":"Error received from peer ipv4:78.41.199.213:443","file":"src/core/lib/surface/call.cc","file_line":1064,"grpc_message":"Deadline Exceeded","grpc_status":4}"

т.е. он возвращает payload == response, success==true, потом должен слать сам ордербук, но вместо этого висит время таймаута и вываливает вот этот эксепшн.

[oakio]

Здравствуйте!
Да проблема действительно была, сейчас должно все работать штатно без зависаний.

[Dronablo]

И опять ордербуки виснут: время - сейчас, примеры id: 7Q5ZP6KPM4B5, 1EG3EKNDNXPX, XETFJEML518N.

[polkila]

Стрим молчит. Нет ответа на запрос о подписке на ордербук.
Также не присылает через стрим отчёт об исполненной заявке. Однако ответ есть success:true

[chumsky]

Добрый день. Есть ли какие то сроки исправления проблемы? Тоже ловлю такие ошибки с orderbook hang. Request id: I2AWZIUJHM8W.
@oakio

[evsamsonov]

У меня похожая проблема. При подключении к GetEvents через 10 минут stream обрывается с ошибкой:
rpc error: code = Canceled desc = stream terminated by RST_STREAM with error code: CANCEL.

[evsamsonov]

@oakio KeepAlive отправляю раз в минуту, не помогает. Как будто сервер сбрасывает, всегда через 10 минут

[oakio]

А ответное сообщение KeepAlive стабильно приходит в течении этих 10 минут?
Если это не регулярная проблема, то возможно сервис перезапускали именно в это время.

[evsamsonov]

@oakio Получаю true на KeepAlive, отдельный сообщений в ответ не получаю. У меня переподключение при такой ошибке. После переподключения через 10 минут снова соединение обрывается и так бесконечно) Уже думаю второе подклчение через 5 минут поднимать, чтобы всегда стабильно получать события(

[oakio]

Да, правильно ResponseEvent с success=true.
Тогда предположу, что между вами и сервисом стоит proxy которое принудительно разрывает долгоживущие соединения. Если есть возможность попробуйте через другого интернет провайдера, к примеру с телефона раздайте интернет в качестве проверки.

[evsamsonov]

Спасибо за оперативный ответ. Запускаю локально и с сервера в vk cloud, везде такая проблема. Попробую еще из других сетей