Сначала получите всю историю исполнения
Сохраните хеш транзакции, точный `sender_account_id` и сеть. Вызовите `tx` с `wait_until: FINAL`. Такой запрос ждёт все квитанции, включая возвраты газа, и окончательность их блоков. При `INCLUDED_FINAL` исходный блок уже окончательный, но часть результатов ещё может отсутствовать. Общая проверка перевода поможет подтвердить хеш и сеть; дальше понадобится именно дерево NEAR.
Список квитанций читают как дерево
`transaction_outcome` описывает, как подписанная транзакция создала начальную квитанцию. Само выполнение контрактов находится в `receipts_outcome`. Начните с идентификаторов в `transaction_outcome.outcome.receipt_ids`, затем переходите по дочерним `outcome.receipt_ids`. Порядок элементов в массиве связь не доказывает.
У каждой ветки свой исполнитель, логи и новые квитанции. Так видны вызов другого контракта, обратный вызов и служебный возврат. Если обычного ответа мало, `EXPERIMENTAL_tx_status` возвращает тела квитанций. Метод `EXPERIMENTAL_receipt` запрашивает одну квитанцию по известному идентификатору.
Исполнение и окончательность движутся отдельно. Окончательный блок исходной транзакции ещё не означает, что последняя ветка выполнилась. Разницу между включением, исполнением и окончательностью удобно сверить с разбором подтверждений и реорганизаций.
| Что сохранить | На какой вопрос отвечает | Граница вывода |
|---|---|---|
| `transaction_outcome.outcome.receipt_ids` | Где начинается дерево | Не показывает выполнение дочерних квитанций |
| `receipts_outcome[].outcome.status` | Какая квитанция получила `SuccessValue` или `Failure` | Не объясняет ожидаемое действие приложения |
| `outcome.receipt_ids` | Какие дочерние ветки создал этап | Не гарантирует их успех |
| `executor_id`, логи и ошибка | Где и почему остановилось выполнение | Логи сами по себе не доказывают изменение данных |
| хеш и высота блока каждой квитанции | К какому окончательному срезу относится вывод | Не заменяет запрос состояния контракта |
| тело квитанции из `EXPERIMENTAL_tx_status` | Кто вызвал контракт и какие действия передал | Требует соответствующего результата исполнения |
- Что сохранить
- `transaction_outcome.outcome.receipt_ids`
- На какой вопрос отвечает
- Где начинается дерево
- Граница вывода
- Не показывает выполнение дочерних квитанций
- Что сохранить
- `receipts_outcome[].outcome.status`
- На какой вопрос отвечает
- Какая квитанция получила `SuccessValue` или `Failure`
- Граница вывода
- Не объясняет ожидаемое действие приложения
- Что сохранить
- `outcome.receipt_ids`
- На какой вопрос отвечает
- Какие дочерние ветки создал этап
- Граница вывода
- Не гарантирует их успех
- Что сохранить
- `executor_id`, логи и ошибка
- На какой вопрос отвечает
- Где и почему остановилось выполнение
- Граница вывода
- Логи сами по себе не доказывают изменение данных
- Что сохранить
- хеш и высота блока каждой квитанции
- На какой вопрос отвечает
- К какому окончательному срезу относится вывод
- Граница вывода
- Не заменяет запрос состояния контракта
- Что сохранить
- тело квитанции из `EXPERIMENTAL_tx_status`
- На какой вопрос отвечает
- Кто вызвал контракт и какие действия передал
- Граница вывода
- Требует соответствующего результата исполнения
Зелёная вершина и упавшая ветка могут сосуществовать
Представим перевод через контракт A. Его квитанция успешно создаёт вызов контракта B, поэтому верхний статус становится зелёным. Квитанция B получает `Failure`. Затем обратный вызов A аккуратно обрабатывает ошибку, а отдельная квитанция возвращает остаток газа. В дереве есть несколько успехов, но перевод не состоялся.
Ищите первый `Failure` по ходу нужной ветки. Запишите идентификатор квитанции, `executor_id`, вызывающий аккаунт, ошибку, логи и дочерние идентификаторы. Откат относится к действиям этой квитанции. Ранее завершённые ветки не превращаются задним числом в общую отмену.
Как читать развязку истории
- `transaction_outcome` с `Failure` означает, что дочерний вызов мог вообще не появиться;
- верхний `SuccessValue` и дочерний `Failure` требуют проверки обратного вызова и данных контракта до повтора;
- `Unknown` или пропавшая квитанция требуют нового запроса с `wait_until: FINAL` и, возможно, архивного RPC;
- успешная квитанция возврата говорит только о возврате неиспользованного газа или депозита;
- успешные прикладные квитанции при старом интерфейсе требуют прямого запроса данных через RPC.
Последнее слово остаётся за состоянием контракта
После разбора дерева запросите показатель, который отражает нужное действие: баланс, запись в хранилище или метод чтения контракта. Используйте окончательный блок. Цвет обозревателя, логи и успешный возврат газа такую проверку не заменяют.
Ошибка доступа, порядкового номера (`nonce`) или подписи относится к отправке либо первой квитанции. Например, FunctionCall access key — ключ ограниченного вызова — может задавать получателя, методы и сумму. Это другая проблема, чем ошибка уже созданной дочерней квитанции. Сначала найдите место `Failure`, затем решайте вопрос с ключом.
Не повторяйте транзакцию, если
- обозреватель показывает один зелёный статус, но не раскрывает все `receipts_outcome`;
- неизвестны `sender_account_id` или сеть, поэтому RPC не находит тот же хеш;
- не проверено, допускает ли метод безопасный повтор без двойного действия;
- обратный вызов успешен, но ожидаемого изменения данных нет;
- результаты получены с разных блоков и выданы за один окончательный срез;
- для диагностики просят сид-фразу, закрытый ключ или новый тестовый платёж.
Неполный ответ RPC не означает, что ветка исчезла
Если два узла дают разные или неполные ответы, сравните их высоту, синхронизацию и глубину истории. Публичный RPC может не хранить старую квитанцию. Эту границу объясняет устройство блокчейн-узла: иногда нужен архивный источник, а не новый перевод.
Источники
Мы используем прямые ссылки и фиксируем дату проверки. Полный текст чужих материалов не перепечатывается.
- NEAR Docs — Lifecycle of a Transaction NEAR · Проверено 25 августа 2026 г. в 00:00 GMT+5
- NEAR RPC — Transactions NEAR · Проверено 25 августа 2026 г. в 00:00 GMT+5
- NEAR Docs — Token Transfer Data Flow NEAR · Проверено 25 августа 2026 г. в 00:00 GMT+5
- NEAR Nomicon — Transaction and Receipt Gas Profiles NEAR · Проверено 25 августа 2026 г. в 00:00 GMT+5
- NEAR mainnet RPC — Status endpoint NEAR · Проверено 25 августа 2026 г. в 00:00 GMT+5