Giao dịch Sui thất bại: Đối tượng được dành riêng cho giao dịch khác

Question

Tôi gặp phải một sự kiên trì JsonRpcErrorkhi cố gắng thực hiện giao dịch trên Sui. Lỗi chỉ ra rằng các đối tượng được dành riêng cho một giao dịch khác, mặc dù tôi đã thực hiện xử lý giao dịch tuần tự với độ trễ. JsonRpcError: Failed to sign transaction by a quorum of validators because one or more of its objects is reserved for another transaction. Other transactions locking these objects: AV7coSQHWg5vN3S47xada6UiZGW54xxUNhRv1QUPqWK (stake 33.83) 0x1c20f15cbe780ee7586a2df90c1ab70861ca77a15970bea8702a8cf97bd3eed9 0x1c20f15cbe780ee7586a2df90c1ab70861ca77a15970bea8702a8cf97bd3eed9 0x1c20f15cbe780ee7586a2df90c1ab70861ca77a15970bea8702a8cf97bd3eed9 Tôi đã thử: Thực hiện giao dịch tuần tự (chờ giao dịch trước hoàn thành) Thêm độ trễ 3 giây giữa các giao dịch Và vẫn gặp phải lỗi tương tự một cách nhất quán. Sử dụng Sui RPC để gửi giao dịch. Cùng một ID đối tượng xuất hiện nhiều lần trong danh sách khóa. Lỗi xảy ra ngay cả với trình tự giao dịch cẩn thận. Điều gì khiến các đối tượng bị “dành riêng” cho các giao dịch khác? Làm thế nào tôi có thể kiểm tra chính xác xem một đối tượng có sẵn hay không trước khi sử dụng nó trong một giao dịch? Có những phương pháp hay nhất để xử lý khóa đối tượng ở Sui không? Điều này có liên quan đến thời điểm cuối cùng của giao dịch không? Có ai gặp phải vấn đề này trước đây không? Bất kỳ thông tin chi tiết nào về quản lý đối tượng phù hợp trong giao dịch Sui sẽ được đánh giá cao!

Owen · Answer

Sui uses optimistic concurrency control, meaning objects are locked when used in a transaction until that transaction is finalized or expires. Even if you wait 3 seconds between transactions, if the previous one hasnt been finalized, the object remains locked. This means that transaction is still pending and holding exclusive access to the object. How to Check If an Object Is Available Use the Sui RPC method: sui_getObject Check response for status: Locked or owner: locked. Example request: { jsonrpc: 2.0, id: 1, method: sui_getObject, params: [0x...object_id...] } If locked, just wait more and retry later.

0xduckmove · Answer

Hey, you are trying to do a transaction too fast and the objects got locked. Try to send one transaction with the same objects at a time, if you send two transactions some validators might accept the first some might accept the second and you objects will be locked because each transactions needs 66.7% of validators and you might be getting only 50%. => just wait for the epoch reset, its soon 🫡 Check more: https://forums.sui.io/t/beginner-tutorial-error-when-deploying-simple-sui-package/44842

MiniBob · Answer

The error means the objects your transaction uses are still locked by previous transactions not yet finalized. Even with delays, objects remain reserved until those transactions complete on-chain. To fix: Always confirm prior transactions involving the objects have fully finalized before using them again. Check object status via Sui RPC to ensure they’re unlocked. Avoid sending parallel or rapid transactions on the same objects. Implement retries with backoff and finality checks instead of fixed delays. This locking prevents conflicting updates and is normal in Sui’s object model. Proper sequencing and finality confirmation are key to avoiding JsonRpcError.

harry phan · Answer

This error happens if you try and run two transactions simultaneously (e.g. start one before the previous one finishes). If you retry running the publish transaction, without running another transaction before or at the same time, it should succeed. You may also need to acquire more gas from the faucet (or wait a day – for the epoch to roll over – for the objects to get unlocked) When you run a transaction that involves objects that your address owns (like the gas objects) validators reserve the latest version of the object to be used by the transaction it is signing. If you try and run two transactions simultaneously and they refer to the same object, then they will compete with each other for signatures from validators. In the happy case, one of the transactions wins, and runs, and the other transaction fails to get enough signatures. In the unhappy case, both transactions can fail to get enough signatures (if both got more than a third of the validator’s signatures, then neither can get over two thirds, which is the threshold), this is called equivocation, and from that point the objects that were inputs to both transactions can’t be used for any other transactions. At the end of the epoch (they are roughly a day long – you can check progress to the next epoch change on https://suiexplorer.com), all locks are released, so you can use the objects again, but if you haven’t had an epoch change since you last tried, you will need to acquire more gas.

24p30p · Answer

On the Sui network, when a transaction attempts to access an object that’s already involved in another in-progress transaction, the network returns a reservation error. This is a direct consequence of Sui’s object-centric execution model. Any transaction that mutates or consumes an object must acquire an exclusive lock on it. Once such a transaction is submitted, the object remains reserved until the transaction reaches finality. That reservation prevents other transactions from interacting with the same object prematurely, thereby ensuring atomicity and avoiding race conditions. However, if finality is delayed due to network latency, validator lag, or unexpected execution behavior, the object can remain locked longer than anticipated. To determine whether an object is in a usable state, you can utilize the sui_getObject method through Sui’s JSON-RPC interface or the Sui CLI. Examining the objects owner field or transaction lock metadata can provide clarity on its status. If the object appears to be in use or does not return ownership to the expected address, it is likely still reserved. An even more robust approach involves programmatically polling the network until the objects lock is released—particularly helpful in automated flows or when orchestrating multiple sequential transactions. Handling these locks effectively demands a few key practices. Its critical to avoid reusing mutable objects across transactions until the previous operations involving them are fully finalized. You should consider using separate or rotating gas coins and object instances wherever possible to reduce contention. Additionally, incorporating retry logic and intelligent polling mechanisms—such as exponential backoff—can minimize transaction failure rates. When transactions are orchestrated in parallel, isolating object usage per process or thread greatly improves reliability. It’s important to note that this behavior is intimately tied to transaction finality. Even if a transaction is accepted into the mempool and broadcasted, the associated object locks remain in place until the network’s validator quorum confirms the transaction’s final state. Any attempt to reuse that object beforehand, regardless of the use of arbitrary time-based delays, will likely result in a reservation error. To streamline object lock handling, here’s a Bash utility you can use in your development workflow. It polls the fullnode and waits for the objects to become unlocked before proceeding with a transaction. This ensures that the object is safe to reuse and mitigates premature failure. Bash Script: wait-for-unlock.sh #!/bin/bash Sui Fullnode RPC endpoint (adjust as needed) RPC_ENDPOINT=https://fullnode.testnet.sui.io:443 Checks if object is locked is_locked() { obj_id=$1 lock_info=$(curl -s -X POST $RPC_ENDPOINT \ -H Content-Type: application/json \ -d { jsonrpc: 2.0, method: sui_getObject, params: [$obj_id], id: 1 }) echo $lock_info | grep -q owner:{AddressOwner && return 1 || return 0 } Waits until each object is no longer locked wait_for_unlock() { for obj_id in $@; do echo Checking object $obj_id... while is_locked $obj_id; do echo Object $obj_id is still locked. Retrying in 2s... sleep 2 done echo Object $obj_id is now unlocked. done } Main handler main() { if [ $# -eq 0 ]; then echo Usage: $0 ... exit 1 fi wait_for_unlock $@ echo All objects unlocked. Safe to proceed with transaction. } main $@ To use the script, simply make it executable and provide the object IDs you want to track. It will poll until those objects are no longer reserved by pending transactions, ensuring your next transaction proceeds smoothly. chmod +x wait-for-unlock.sh ./wait-for-unlock.sh 0xYOUR_OBJECT_ID This type of automation is especially effective when integrated into deployment scripts or CI/CD pipelines, providing a layer of resilience in high-throughput or multi-user applications.

casey · Answer

You are simply his error due to the fact that you are trying to run more than one transaction at once, probably trying to send bundled transactions. What causes objects to be reserved for other transactions? Answer: That error means your transaction tried to use an object (token, nfts, etc.), in this case, your gas coin(tx.gas) that’s already “locked” by another in-flight transaction on the Sui network. Sui objects are single-use per transaction, and until the transaction that’s locking them is confirmed or expires, you can’t use them again immediately(i.e when you recently send a transaction, the network may still be processing it, so the coin is temporarily reserved until transaction is completely executed). How can I properly check if an object is available before using it in a transaction? Answer: you wait for your first transaction to be completed or failed, this means the gas coin(tx.gas) reserved by the network tempoarily has been released when transaction is completed or when it fails. You can check transaction status by using: bash sui client tx-status Are there best practices for handling object locks in Sui? Answer: yes there is, Wait for the earlier transaction to finish or fail (can take up to 20 seconds on testnet) before executing a new transaction, and you can always confirm that your transaction is already completed before executing a new transaction. You can also try to SPLIT YOUR SUI INTO MULTIPLE GAS COINS This way, even if one coin is locked, you can use another immediately by using js const tx = new Transaction(); const [newGas] = tx.splitCoins(tx.gas, [tx.pure.u64(1_000_000_000n)]); // 1 SUI tx.transferObjects([newGas], tx.pure.address(ownAddress)); Run it once, and you’ll have multiple small gas coins in your account. Could this be related to transaction finality timing? Answer:Yes this is related to transaction finality, am guessing the added 3-second delays between transactions isnt enough for a transaction to be completely finalized, you can always check your transaction status using sui client tx-status

d-podium · Answer

The error youre encountering occurs due to Suis transaction locking mechanism, which prevents double-spending and ensures atomic operations. Let me explain exactly whats happening and how to fix it. Understanding Transaction Locking in Sui When a transaction is submitted to the Sui network, validators lock the referenced owned objects to prevent concurrent modifications. This locking mechanism is fundamental to preventing double-spending and ensuring transaction atomicity. Why Current Solutions Arent Working Your current approach of adding 3-second delays between transactions isnt effective because: Transaction finality can take longer than 3 seconds. Multiple transactions might be competing for the same objects. The network doesnt guarantee immediate object availability after transaction completion. Step-by-Step Solution Implement Proper Transaction Status Checking; async function waitForTransaction(txDigest) { const MAX_RETRIES = 30; const RETRY_DELAY_MS = 1000; for (let attempt = 0; attempt setTimeout(resolve, RETRY_DELAY_MS)); continue; } throw error; } } } Check Objective Availability Before Transactions; async function checkObjectAvailability(objectId) { try { const result = await suiClient.objects({ ids: [objectId], options: { showPreviousVersion: true } }); // Object is available if we can fetch it successfully return result.details.length > 0; } catch (error) { return false; } } Implement Transactions Retries with Backoff; async function executeTransactionWithRetry(txBuilder, signer) { const MAX_RETRIES = 5; const INITIAL_BACKOFF_MS = 500; for (let attempt = 0; attempt setTimeout(resolve, backoffMs)); } } } Best Practices for Object Management Always Verify Transaction Status Wait for effects certificates before considering transactions complete Check transaction status regularly during processing Implement proper error handling for locked objects Object Availability Checks Verify object availability before transaction creation Handle cases where objects become locked during preparation Consider implementing object reservation mechanisms in smart contracts Transaction Sequencing Use effects certificates as confirmation of completion Implement exponential backoff for retries Maintain transaction ordering through proper dependency management Error Handling Distinguish between temporary locking errors and permanent failures Implement proper retry logic with backoff Maintain transaction history for debugging purposes Additional Considerations Epoch Changes Transactions may fail during epoch transitions Implement retry logic specifically for epoch-related failures Consider transaction timing relative to epoch boundaries Network Congestion Monitor network load during peak times Adjust backoff strategies based on network conditions Consider implementing rate limiting for high-frequency transactions By implementing these solutions and following the best practices outlined above, you should be able to effectively handle object locking scenarios and prevent the JsonRpcError youre encountering. Remember that proper error handling and retry mechanisms are essential for reliable transaction processing on the Sui blockchain.

BigDev · Answer

This error means the objects you’re using are still locked by earlier transactions that haven’t finalized yet. Even with delays, Sui keeps them reserved until the chain confirms completion. To fix it, make sure any previous transactions using those objects are fully finalized before reusing them. You can check their status through Sui RPC to see if they’re unlocked. Avoid sending multiple or rapid transactions involving the same objects. Instead of relying on fixed delays, use retries with backoff and confirm finality before retrying. This locking is part of how Sui ensures safe updates, so proper sequencing and checking finality is the way to avoid JsonRpcError

Bài viết

Chia sẻ kiến thức của bạn.

Giao dịch Sui thất bại: Đối tượng được dành riêng cho giao dịch khác

Câu trả lời

Cách kiểm tra xem một đối tượng có sẵn không

Bạn có biết câu trả lời không?

Kiếm phần của bạn từ 1000 Sui