В последовательном режиме Aptos более поздняя транзакция не выполнится, пока аккаунт не достигнет нужного ей номера. Поэтому невыясненная ранняя попытка способна задержать следующую даже при достаточном балансе. Сначала проверьте исходный хеш и реальный результат. У Aptos также есть orderless-транзакции с другой защитой от повторного исполнения, для которых объяснение очереди отличается.
Номер относится к последовательности отправляющего аккаунта
Описание аккаунтов Aptos связывает sequence number с отправленными и зафиксированными транзакциями, включая завершённые abort. При обычном последовательном выполнении номер запроса должен совпадать со следующим номером аккаунта. Поэтому место в очереди и успех платежа — разные сведения. Изменение счётчика не заменяет проверку получателя, актива и фактической передачи средств.
Руководство управления транзакциями объясняет, почему узел может принять запрос с будущим номером, но пока не передавать его дальше: должна быть учтена предшествующая последовательность. Принятие через интерфейс отправки не равно фиксации в блокчейне. Общий баланс APT или другого токена также не отвечает на вопрос об очередности действий.
| Какие сведения есть | Возможный смысл | Что проверить |
|---|---|---|
| Поздний последовательный запрос ждёт | Не разрешён предыдущий номер | Прежнюю транзакцию и текущий счётчик аккаунта |
| SEQUENCE_NUMBER_TOO_OLD | Этот номер уже использован в реестре | Какая транзакция его заняла и с каким результатом |
| Слишком новый номер при симуляции | Проверяемое значение выше следующего номера | Ранние попытки и состояние снимка расчёта |
| Зафиксированная транзакция с abort | Запись есть, но действие не удалось | Статус выполнения, газ и актуальную последовательность |
| Orderless-запрос с nonce | Действует другая защита от повторов | Его хеш, контекст nonce и результат |
Разберите два платежа в правильном порядке
Вымышленный аккаунт ожидает номер 41. Кошелёк готовит платёж Cedar с 41 и Maple с 42. Если узел не видел Cedar и не получил сведения о фиксации 41 в другом месте, Maple не может просто выполнить действие, пропустив номер. Повторное нажатие отправки само по себе не определяет, какая попытка занимает эту позицию и состоялся ли первый платёж.
Если Cedar выполнен успешно, сначала проверьте получателя и сумму, затем решайте вопрос о замене. Если Cedar зафиксирован с ошибкой исполнения, аккаунт всё ещё способен продвинуться, но задуманный платёж этим не подтверждается. Результат Maple проверяется отдельно. Порядковый номер объясняет очерёдность, а не служит общим подтверждением оплаты сразу двух переводов.
Если Cedar истёк без фиксации, не предполагайте автоматическое продвижение аккаунта до 42 только из-за истечения. Сопоставьте актуальное состояние и оставшиеся попытки. Обнуление таймера интерфейса не разрешает использовать старые локальные сведения и заново подписывать все элементы со статусом ожидания. Сначала нужно выяснить, что действительно осталось невыполненным, иначе возможна лишняя оплата.
Отличайте зафиксированный abort от отказа отправки
Документация транзакций и состояний разделяет отправку и исполнение, а в результате указывает расход газа и статус. Часть неудачных действий имеет зафиксированную запись, другие запросы отклоняются раньше. Если считать любую ошибку бесплатной и никогда не исполнявшейся попыткой, можно неверно объяснить и остаток средств, и занятый порядковый номер.
В справочнике поиска по хешу для соответствующих записей предусмотрены success и vm_status. Прочитайте их и сопоставьте задуманное движение актива. Само наличие хеша или версии реестра не подтверждает получение нужной суммы нужного токена. Для разбора платежа важны и факт фиксации, и смысл фактического исполнения.
Например, приложение может показать ошибку действия после того, как транзакция уже заняла место последовательности в реестре. Новая попытка должна учитывать это состояние. Но отказ отправки сам по себе ещё не доказывает сетевое списание. Смотрите записанный результат вместо выводов по красному баннеру или разнице общего баланса, в которую могли войти другие операции.
Не перенумеровывайте запросы вслепую
Официальный справочник ошибок описывает слишком старые и слишком новые номера. Это повод синхронизировать запрос с аккаунтом, а не подобрать произвольное большее число. Больший номер способен оставить новый разрыв, а уже использованный занят. Простое изменение цифры не устанавливает судьбу прежнего платежа и не делает повтор безопасным автоматически.
Несколько клиентов могут по-разному представлять следующий свободный номер. Руководство транзакций предупреждает об устаревшем локальном состоянии отдельных менеджеров. Пользователю стоит приостановить конкурирующие отправки из других вкладок и приложений на время выяснения результата. Очистка истории в интерфейсе не меняет счётчик аккаунта в блокчейне: локальный список и состояние реестра — не одно и то же.
Комиссия и порядок также различаются. Повышение параметра газа не превращает отсутствующего предшественника в зафиксированную операцию. Не делайте серию изменений комиссии при неизвестной судьбе первой попытки. Пересобранному платежу нужны актуальные срок, получатель и актив. Исправленный счётчик ещё не удостоверяет остальные реквизиты, особенно если изменились инструкции принимающей платформы.
Где объяснение меняют orderless-транзакции
AIP-123 и руководство orderless описывают nonce вместо обычного последовательного счётчика. Такие операции могут выполняться без той же зависимости от предыдущего номера. Поэтому фраза «любой платёж Aptos ждёт предыдущую транзакцию» слишком широка. Сначала выясните используемый режим, затем применяйте подходящий способ поиска и диагностики.
Не исправляйте существующий запрос кошелька ручным превращением в другой тип транзакции. Поддержка зависит от приложения, способа подготовки и сети. Orderless-попытку проверяют по её собственному хешу и результату. Изменение обычного sequence number аккаунта не является полным трекером такого режима. Сравнивать нужно соответствующие идентификаторы, не подменяя их привычным счётчиком.
У orderless остаются правила срока действия и защиты от повторов. Это не способ игнорировать истёкший запрос либо без проверки повторить платёж. Различие касается идентификации и порядка исполнения, а не обещания завершить любую альтернативную отправку. Пользовательский интерфейс может скрывать часть технических полей, поэтому при сомнении уточните режим по официальной документации кошелька.
Соберите согласованный набор сведений для поддержки
- Проверьте сеть, отправляющий аккаунт и тип защиты от повторного исполнения. Сохраните исходный хеш и точную ошибку.
- Разберите раннюю попытку перед поздней. Отметьте ожидание, успех, зафиксированную ошибку либо отсутствие записи у проверенного источника.
- Для последовательного запроса сопоставьте его номер с текущим состоянием аккаунта. Учтите другие приложения с правом отправки.
- Прочитайте success и подробности исполнения, затем проверьте получателя, актив и сумму. Не выводите успех только из роста счётчика.
- При истечении обновляйте данные поддерживаемым способом после сверки оставшихся попыток. Не подписывайте автоматически копии всей очереди.
- Передайте хеши, аккаунт, сеть и сведения о результатах. Сид-фраза и приватный ключ для публичной проверки не нужны.
Отсутствие результата на одном адресе API оставляет вопрос, а не доказывает безвредность замены. Внутренний депозит платформы проверяется отдельно после исполнения в сети. Если нужный перевод уже успешен, передайте запись получателю вместо автоматического второго платежа. Укажите, какой именно этап не совпадает: блокчейн, отображение кошелька или внутренний учёт принимающей стороны.
Для общего сбора доказательств есть проверка транзакции по хешу. При обмене без регистрации отделяйте номер заявки от хеша Aptos. Раздел как работает сервис описывает процесс обмена, но не превращает ожидающий запрос кошелька в зачисленный депозит и не обещает поддержку любого формата транзакции.
Частые вопросы
Как проверить перевод Aptos, если он ждёт предыдущую транзакцию?
Найдите ранний хеш и сопоставьте его реальный результат с последовательностью аккаунта. В последовательном режиме неразрешённый предыдущий номер важен, даже когда поздний запрос уже принят узлом.
Доказывает ли хеш транзакции Aptos успешную оплату?
Нет, нужно прочитать success, статус исполнения и движение актива. Зафиксированный abort может занимать номер без завершения задуманного платежа.
Можно ли отслеживать все операции Aptos только по sequence number?
Нет, orderless использует другой режим с nonce. Каждую операцию проверяют по хешу и результату, не считая обычный счётчик универсальной квитанцией.