Перейти к основному содержанию
OrbitFlare предоставляет два gRPC-сервиса. Большинство проблем возникает из-за того, что путают их хосты, порты или способ аутентификации, поэтому сначала проверьте это: Способ доступа зависит от режима аутентификации вашей лицензии:
  • IP Whitelist: подключение должно идти с IP из белого списка вашей лицензии. Ключ не нужен, а с любого другого IP один ключ доступа не даст. Чтобы узнать IP, с которого подключается сервер, выполните на нём curl -s ifconfig.me.
  • API Key Only: передавайте ключ лицензии в заголовке метаданных x-token с любого IP. В gRPC нет строки запроса, а x-api-key не принимается.
Прежде чем отлаживать что-то ещё, проверьте режим лицензии в панели управления.

​
Проверьте подключение через grpcurl

grpcurl вызывает gRPC-метод из командной строки, поэтому доступ можно проверить без написания кода. Скачайте proto-файлы из репозитория SDK в текущую папку, затем:
В режиме IP Whitelist флаг -H можно не указывать. Строка с версией означает, что хост доступен и вас пропускают. При любом другом ответе найдите его ниже.

​
Ошибки и их значение

​
Доступ запрещён

Два сервиса сообщают об этом по-разному, и одно и то же сообщение может означать разное в каждом режиме аутентификации. Jetstream закрывает соединение, не отправив никакого gRPC-статуса, поэтому EOF или сброс соединения — единственный признак, который вы получите. Если эндпоинт не входит в вашу лицензию, обращение к нему в любом режиме приводит к такому же EOF. Проверьте, какие регионы включены в лицензию, в панели управления. SDK оборачивают эти ошибки, добавляя номер gRPC-статуса и эндпоинт, например grpc error (16): authentication required: provide x-token header в Rust или grpc error (14): [http://ams.jetstream.orbitflare.com] error reading from server: EOF в Go. Статус 16 — это Unauthenticated, 7 — PermissionDenied, а 14 — Unavailable. Если один и тот же код работает с одного сервера и не работает с другого, почти наверняка у вас режим IP Whitelist и IP второго сервера нет в списке. Если в режиме API Key Only ошибка возникает везде, проверьте, что клиент действительно отправляет заголовок x-token.

​
Неверный транспорт или порт

​
Достигнут лимит соединений

RESOURCE_EXHAUSTED: connection limit exceeded означает, что у вашего IP уже открыто 50 gRPC-соединений, считая Jetstream, Yellowstone и все регионы вместе. Закройте потоки, которые больше не используете, и размещайте несколько фильтров в одном потоке вместо отдельного потока на каждый фильтр. См. лимиты соединений.

​
Соединение есть, но ничего не приходит

​
Jetstream

Jetstream v2 сообщает, принят ли каждый фильтр. Первое сообщение в новом потоке — filterValidation для каждого отправленного фильтра:
Отклонённый фильтр не закрывает поток. Вы продолжаете получать heartbeat-сообщения, поэтому соединение выглядит исправным, хотя совпадений нет. Логируйте сообщения filterValidation и проверяйте accepted, прежде чем решить, что на рынке просто тихо. Другие причины:
  • Вы запросили аккаунты. Jetstream передаёт только транзакции. Фильтры по аккаунтам не поддерживаются, и подписка v1 с фильтром accounts никогда ничего не отправит. Для отслеживания состояния аккаунтов используйте Yellowstone.
  • account_required слишком строгий. account_include находит транзакцию, в которой упоминается любой из перечисленных аккаунтов. account_required находит только транзакции, в которых упоминаются все они. Начните с account_include и сужайте выборку от него.
  • Вы вызвали SubscribeParsed. Этот метод не реализован и завершается с Unavailable: EOF. Используйте Subscribe (v1) или SubscribeTransactions (v2) и декодируйте инструкции самостоятельно.

​
Yellowstone

  • Карта фильтров пуста. SubscribeRequest без фильтров корректен и ничего не возвращает. Каждому фильтру нужно имя: {"accounts": {"my-filter": {"account": ["..."]}}}.
  • Аккаунт не меняется. Фильтры по аккаунтам отправляют обновление только при изменении аккаунта. Проверьте на SysvarC1ock11111111111111111111111111111111, который меняется каждый слот.
  • Неудачные транзакции отфильтрованы. failed: false отбрасывает все транзакции, завершившиеся ошибкой. Во время отладки не задавайте этот параметр, чтобы видеть, попадают ли ваши транзакции в блок и не завершаются ли они ошибкой. (Фильтр vote больше не имеет значения: после Alpenglow валидаторы голосуют вне блокчейна, и в mainnet нет транзакций голосования.)

​
Потоки, которые останавливаются

Простаивающие gRPC-потоки закрываются примерно через 10 минут. Отправляйте ping в поток каждые 30 секунд:
  • Jetstream v2: отправьте сообщение ping в поток SubscribeTransactions. Сервер ответит pong с тем же идентификатором.
  • Yellowstone: отправьте SubscribeRequest, в котором задан только ping. См. Быстрый старт Yellowstone.
SDK OrbitFlare отправляют ping, обнаруживают пропущенные pong, переподключаются с экспоненциальной задержкой и автоматически отправляют ваши фильтры заново. Если вы используете собственный клиент, после переподключения отправляйте подписку целиком, потому что фильтры привязаны к потоку и теряются вместе с ним.

​
Если проблема не решена

Соберите хост и порт, вызванный метод, отправленный фильтр, точный текст ошибки с кодом статуса и публичный IP, с которого вы подключаетесь. Затем задайте вопрос в Discord.