Повторная пересылка тех же подписанных данных Solana отличается от новой подписи платежа со свежим blockhash. В первом случае сохраняется идентификатор одной транзакции, во втором появляется ещё одна попытка, которая может исполниться самостоятельно. До новой подписи выясните, что произошло с исходной отправкой и может ли она ещё быть принята. Ответ RPC или таймаут кошелька отдельно не отвечают на оба вопроса.
Одна кнопка Retry может означать разные действия
Приложение может снова передать прежние подписанные данные, а может пересобрать платёж и запросить подпись. По названию кнопки различие не видно. Сохраните первый идентификатор и сопоставьте последующий, если он появился. Также проверьте актив, получателя и сумму. Новая подпись указывает на другую попытку, но сама по себе ещё не доказывает второго успешного поступления. Для такого вывода нужно исполнение и соответствующее движение к получателю.
В справке sendTransaction указано, что RPC пересылает подготовленную транзакцию без изменения и при принятии возвращает её первую подпись. Ответ не дожидается подтверждения и не обещает исполнение. Поэтому идентификатор может быть уже известен, а платёж ещё не выполнен. Неясный результат ожидания в приложении тоже не доказывает отсутствие отправки. Сверяйте сетевую запись, а не принимайте каждое локальное сообщение за окончательный итог.
| Действие или признак | Идентичность попытки | Что проверить до повтора оплаты |
|---|---|---|
| Снова отправлены те же подписанные байты | Сохраняется прежняя подпись | Состояние и результат этой операции |
| Свежий blockhash и новая подпись | Другая подписанная транзакция | Может ли ещё исполниться исходная |
| Получатель и сумма те же, подпись другая | Самостоятельная попытка | Оба результата, а не внешнюю похожесть |
| RPC вернул идентификатор | Свидетельство принятия запроса | Статус и ошибку исполнения при наличии |
| Кошелёк перестал ждать | Таймаут приложения | Подтверждение, истечение или неопределённость исходной попытки |
| Один поиск не вернул статус | Нет результата этого поиска | Кластер, глубину истории и данные действительности |
Учебный пример с двумя подписями
Предположим, A платит B четыре единицы токена, исходная попытка имеет подпись S1. Соединение ожидания прервалось, и приложение переслало те же данные. Обе отправки относятся к S1. Их нельзя складывать как два отдельных платежа только по числу запросов или уведомлений. Найдите результат S1 и фактическое движение токена. Повтор сообщения интерфейса не является доказательством, что получатель получил дополнительные четыре единицы.
Теперь приложение вместо пересылки получает новый blockhash и запрашивает подпись S2 для той же суммы. Если S1 ещё действительна, обе попытки способны исполниться. Тогда получатель может получить восемь единиц вместо четырёх. В инструкции Solana о повторных отправках отдельно предупреждают о новой подписи до истечения исходного blockhash. Обозначения и количества вымышлены; они показывают учёт риска, а не предлагают код отправки.
Но сама S2 не доказывает получение восьми. Одна попытка могла завершиться ошибкой, устареть или вообще не попасть в отправку. Откройте обе записи и сопоставьте реальные поступления. Если успешна одна, её и укажите как выполненную оплату, сохранив вторую как историю. В руководстве по Solscan разобрано различие между общей активностью адреса и конкретными движениями операции. Это позволяет считать фактически полученное, а не число подписей в переписке.
Истечение срока не доказывает, что раньше исполнения не было
Для обычной транзакции с recent blockhash сохраняйте сведения о действительности, включая lastValidBlockHeight, полученные при подготовке. Используйте документированную проверку подтверждения и подходящие наблюдения сети вместо произвольного ожидания по секундомеру. Таймаут кошелька может закончиться раньше окна принятия. Но завершившееся окно также не доказывает, что попытка не была обработана до его конца. Нужно выяснить прошлый результат и возможность будущего принятия отдельно.
Документация getSignatureStatuses различает поиск в недавних статусах и обращение к истории транзакций. Пустой ответ одного запроса нельзя автоматически назвать доказательством неисполнения. Проверьте кластер, доступность истории и сведения получателя. В объяснении подтверждения и истечения описана роль recent blockhash. Транзакции с durable nonce имеют другой жизненный цикл: к ним нельзя механически применять правило ожидания из обычной отправки.
- Сохраните исходную подпись, кластер, ожидаемый перевод и имеющиеся данные срока действия.
- Проверьте статус и результат исполнения этой подписи.
- Установите, повторяет ли Retry прежние данные или создаёт новую подпись.
- Перед новой подписью выясните исход первой попытки и возможность её дальнейшего принятия.
- Сверьте все подписи-кандидаты с реальными движениями к получателю.
- При двойном исполнении сообщите получателю обе записи вместо ещё одного корректирующего платежа.
Изменение подписанных полей — новая точка решения
Blockhash входит в сообщение, которое подписывается. Его замена или изменение инструкции не являются невидимой правкой прежней квитанции. Не соглашайтесь на уверение приложения «просто обновили платёж» без проверки идентификатора и ожидаемого действия. Ошибка проверки подписи также не равна успешному распространению. Сохраните точный отказ, а не меняйте поля многократно, пока интерфейс не покажет желаемую отметку. Важно понять, какая инструкция получила действующую авторизацию.
Разработчику стоит хранить бизнес-номер оплаты отдельно от подписей возможных попыток. Разделяйте принятие запроса, подтверждение и исполнение, связывая последующие кандидаты с одним ожидаемым платежом. Повторные нажатия не должны незаметно создавать независимые оплачиваемые инструкции. Документированный механизм повторной пересылки и соблюдение лимитов RPC полезнее агрессивного цикла запросов. Большое число отправок само по себе не исправляет отсутствие учёта результата и может затруднить разбор.
Сверьте результат с условиями получателя
У обмена без регистрации есть инструкции конкретной заявки: актив, сеть, сумма и окно оплаты. Сетевой повтор не продлевает их автоматически. Если исполнились две подписи, передайте обе и поясните, что они относились к одному заказу. Не рассчитывайте на автоматическое объединение и не добавляйте ещё одну сумму ради исправления записи. Сначала получателю нужны доказательства того, что уже произошло, а не новая неопределённая отправка.
Если отказ связан именно с недоступным blockhash, начните с разбора Blockhash Not Found. Решение о повторе всё равно требует отдельной сверки: какая транзакция существует, что она выполнила и может ли новая попытка дублировать результат. В итоговой заметке перечисляйте исполненные движения и неразобранные кандидаты. Число нажатий Send или показанных уведомлений не заменяет такого учёта и не подтверждает сумму у получателя.
Частые вопросы
Что идентифицирует Solana transaction signature?
Первая подпись используется как идентификатор транзакции. При повторной пересылке тех же подписанных данных речь идёт о той же идентичности попытки.
Как новая подпись Solana отличается от пересылки прежней?
Пересборка с изменённым подписываемым сообщением создаёт другую транзакцию. До её авторизации нужно разобраться, может ли исходная тоже исполниться.
Почему после изменения blockhash возможна signature verification failure?
Старую подпись нельзя применить к произвольно изменённому сообщению. Пользуйтесь документированным процессом кошелька, не редактируя подписанные данные вручную.