Ошибка Tezos «counter in the past» означает, что номер отправленной управляющей операции меньше ожидаемого в текущем контексте узла. Перед новым платежом проверьте включённую историю отправителя, актуальный counter и ожидающие попытки. Ошибка сама по себе не подтверждает перевод получателю, а слепая замена номера может привести к повторной оплате.
Счётчик относится к отправляющему аккаунту, а не экрану платежа
Counter упорядочивает управляющие операции Tezos и защищает от повторного воспроизведения. В справочнике ошибок RPC различаются уже использованный и ещё не достигнутый номера; данные ошибки содержат expected и found. Полный идентификатор может включать префикс протокола. Сохраните сообщение целиком, а не сравнивайте его только со старым скриншотом.
Один отправитель может использоваться в нескольких приложениях. Делегирование, вызов контракта или другая управляющая операция способны влиять на ситуацию, хотя сейчас открыт экран обычного перевода. В обзоре операций OpenTezos объяснено, почему понятие operation шире платежа. Стройте хронологию по активности аккаунта, а не по одному разделу приложения.
Вымышленный пример: включённый счётчик аккаунта уже равен 43, а черновик всё ещё содержит 42. В этом контексте черновик устарел. Но из этого не следует, что операция 43 перевела нужную сумму. Откройте её содержимое и результат. Изменение номера не является подтверждением получения монет адресатом, даже если кошелёк убрал прежнее предупреждение.
Черновик, мемпул узла и результат в блоке — разные сведения
Приложение может помнить черновик или попытку отправки, которая не попала в блок. В описании prevalidator Octez рассмотрена классификация до включения и её пересмотр при смене вершины цепи. Поэтому у отметки pending нужно понимать источник и время наблюдения. Одинаковое слово в разных интерфейсах не гарантирует одинаковый этап.
| Наблюдение | Что оно подтверждает | Что проверить дальше |
|---|---|---|
| В кошельке есть локальная ожидающая запись | Приложение помнит попытку | Хеш и наличие сведений об операции у узла или в блоке |
| Узел показывает операцию в мемпуле | Этот узел видел её до включения | Классификацию, counter и текущий контекст цепи |
| Операция включена с неуспешным результатом | Включение состоялось без нужного успешного исполнения | Точную ошибку, комиссии и актуальное состояние аккаунта |
| Счётчик выше ожидаемого черновиком | Черновик отстаёт от наблюдаемого состояния | Какие включённые операции продвинули счётчик |
| Нужный перевод применён для нужного получателя | Есть свидетельство конкретного платежа в цепи | Актив, сумму и отдельное внутреннее зачисление сервиса |
В описании мемпула протокола проверка операций отделена от их фактического применения. Поэтому принятие кандидата узлом ещё не выполненный перевод. Сохраняйте эти наблюдения раздельно, даже если кошелёк показывает их в одной истории. Это помогает не превратить предположение приложения в подтверждённую запись учёта.
Перед повтором разберите исходный платёж
- Сохраните исходный хеш, адрес отправителя, получателя, актив, сумму и полное сообщение о counter.
- Убедитесь, что кошелёк и обозреватель смотрят на одну сеть и один отправляющий аккаунт.
- Найдите исходную операцию и свежую включённую историю отправителя, а не только баланс получателя.
- Прочитайте результаты нужных элементов и проверьте ожидающие попытки того же отправителя.
- Обновите состояние аккаунта в кошельке; не подбирайте номер вручную при неясном результате первого платежа.
- Подписывайте пересобранный перевод только после выяснения, почему исходная попытка не выполнила нужное действие и нужен ли новый платёж.
В официальном руководстве по обозревателям Tezos перечислены средства просмотра операций и истории. Если один интерфейс не показывает нужные детали, используйте другой подходящий источник. Пустой результат поиска повод проверить сеть и охват сервиса. Он сам по себе не доказывает, что операция никогда не появится в цепи.
Неуспешный пакет может находиться в блоке без выполнения платежей
В справке действующего протокола о проверке и применении допустимость включения отделена от успешного исполнения. Там также описаны комиссии и продвижение счётчика при неуспешной управляющей операции. Поэтому изменение counter нельзя использовать вместо чтения результата конкретного перевода. Уменьшение баланса тоже требует расшифровки, а не автоматического вывода об оплате.
Одна отправка может содержать несколько управляющих элементов. Справка о блоках и операциях описывает их последовательное атомарное применение. Обратите внимание на результаты backtracked, failed и skipped. Одного элемента, похожего на перевод, внутри включённой группы недостаточно для подтверждения фактической оплаты. Проверять нужно его окончательный результат и связанные изменения.
Например, вымышленный пакет содержит перевод, после которого неудачно вызывается контракт. Верхняя строка обозревателя может показывать группу в блоке, а подробности объяснят, почему нужные прикладные изменения не сохранились. До сверки элементов не отправляйте ту же сумму снова. Актуальный counter перечитайте из состояния, а не восстанавливайте подсчётом видимых строк: интерфейс может показывать не все нужные действия.
Counter in the future требует другой проверки порядка
При counter in the future запрос опережает ожидаемый номер в проверяемом контексте. Может потребоваться разобраться с предыдущими действиями, а не просто ждать условные десять минут. Уточните, какую предшествующую операцию кошелёк считает выполненной. Повышение комиссии поздней попытки само не делает пропущенную раннюю операцию включённой. Причина конфликта порядка и готовность платить больше — разные вопросы.
Сопоставьте планируемую приложением очередь и фактическое состояние цепи. На время проверки прекратите создавать новые черновики. Если аккаунт используется несколькими приложениями, сначала согласуйте эту активность. В обращении к поддержке разделите попытки: слово «повтор» не должно скрывать два разных хеша с одинаковой суммой и получателем. Иначе легко обсуждать результат одного платежа, имея в виду другой.
Обновление интерфейса не отменяет подписанную операцию
Когда локальное состояние расходится с цепью, используйте документированный порядок обновления или восстановления кошелька. Удаление строки из истории не подтверждает отмену ранее подписанной операции. До переустановки сохраните обычную резервную копию и публичные сведения о попытках. Не отправляйте секретные слова поддержке и не используйте предложенный незнакомцем сайт для ремонта счётчика.
Полезное обращение выглядит конкретно: сеть, отправитель, исходный хеш, expected X и found Y в такое-то время, последующие включённые действия и оставшиеся неясные попытки. Укажите, кто получатель — собственный кошелёк или сервис. Такой набор показывает вопрос для проверки без неподтверждённого заявления о пропаже денег. Ключи и резервная фраза для чтения этой публичной хронологии не нужны.
Для депозита отдельно проверяются исполнение в цепи и внутреннее зачисление сервиса. Контекст актива есть на странице XTZ, а поиск публичного идентификатора разобран в руководстве по хешу транзакции. Перед новым простым обменом сверьте исходный платёж и действующую инструкцию заявки. Новая заявка сама не исправляет старый конфликт счётчика.
Частые вопросы
Исправит ли повышенная комиссия Tezos ошибку counter in the past?
Повышенная комиссия не превращает устаревший номер в ожидаемый. Сначала разберите предыдущие операции и обновите состояние, затем решайте, нужен ли новый перевод.
Может ли комиссия Tezos списаться без успешной оплаты получателю?
Да, включённая управляющая операция может завершиться ошибкой исполнения. Проверьте результаты элементов и изменения получателя вместо вывода об оплате по одному списанию.
Означает ли pending, что комиссия и перевод Tezos уже окончательны?
Нет, локальная ожидающая запись или наблюдение в мемпуле отличаются от результата включённой операции. Найдите операцию в правильной сети и прочитайте исполнение до отражения платежа в учёте.