eztz.contract.sendの後にeztzでトランザクションステータスを監視する方法
-
-
[トランザクションが失敗した理由を理解するにはどうすればよいですか?](https://tezos.stackexchange.com/questions/172/how-can-i-understand-why-a-transaction-has-failed)の重複の可能性Possible duplicate of [How can I understand why a transaction has failed?](https://tezos.stackexchange.com/questions/172/how-can-i-understand-why-a-transaction-has-failed)
- 2
- 2019-02-06
- Ezy
-
eztz自体が呼び出し操作内でブロックを受信するため、ブロックはありません.I do not have a block, because eztz itself causes a block to be received inside the call operation
- 0
- 2019-02-06
- Михаил Магомедов
-
申し訳ありませんが、eztzが「呼び出し操作内でブロックを受信する」とはどういう意味ですか?コンテキストを明確に理解できるように、実行していることとトランザクションのステータスに関する詳細/情報を提供してください.ありがとうございました!sorry what do you mean that eztz "causes a block to be received inside the call operation" ? Please can you provide more details/infos about what you are doing and what is the status of the transaction so we understand clearly the context. Thank you!
- 0
- 2019-02-06
- Ezy
-
eztz.contract.sendメソッドを呼び出した後にブロックID(eztz.rpc.getHead())を受け取った場合、それが変更される可能性がありますか?Could it be that the block id(eztz.rpc.getHead()) will change if I receive it after calling the eztz.contract.send method?
- 0
- 2019-02-06
- Михаил Магомедов
-
あなたが言っていることは私には意味がありません.eztzが返すメッセージをここに貼り付けることができますか?そうすればもっと簡単になります.TzScanでトランザクションを見つけることができますか?it does not make sense to me what you are saying. Can you paste here the message that eztz returns you ? it will be simpler that way. Can you find the transaction in TzScan ?
- 0
- 2019-02-06
- Ezy
-
私はeztz.contract.sendを使用し、彼はトランザクションハッシュooTC8mMZ7dG1ReCXLPiTAN3qEUB7uNFuh9R8KZXEFbZZiZcypBfと、eztzでトランザクションステータスを監視する方法のみを返します.ブロックIDがわかりませんi use eztz.contract.send and he return me only transaction hash, ooTC8mMZ7dG1ReCXLPiTAN3qEUB7uNFuh9R8KZXEFbZZiZcypBf and how watch transaction status with eztz. I dont know block id
- 0
- 2019-02-06
- Михаил Магомедов
-
代わりにチャットに行きましょうlet's go to chat instead
- 0
- 2019-02-06
- Ezy
-
[チャットでこのディスカッションを続けてください](https://chat.stackexchange.com/rooms/89334/discussion-between-ezy-and--).Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/89334/discussion-between-ezy-and--).
- 0
- 2019-02-06
- Ezy
-
3 回答
- 投票
-
- 2019-02-13
実際には、これを実行するeztzの新しい関数があります:
eztz.rpc.awaitOperation( opHash, //The operation hash to watch interval, //Optional - Time between checks, defaults to 30 seconds timeout//Optional - Timeout - will end after this, defaults to 180 seconds ).then(function(blockHash){ //Will resolve with the blockHash if found console.log("Found in block " + blockHash) }).catch(function(){ //Reject on time out };
デフォルトを使用すると、問題なく機能するようです(約3ブロック待機します).
There's actually a new function with eztz that does this now:
eztz.rpc.awaitOperation( opHash, //The operation hash to watch interval, //Optional - Time between checks, defaults to 30 seconds timeout//Optional - Timeout - will end after this, defaults to 180 seconds ).then(function(blockHash){ //Will resolve with the blockHash if found console.log("Found in block " + blockHash) }).catch(function(){ //Reject on time out };
Using the defaults seem to work fine for me (waits approx 3 blocks).
-
- 2019-02-06
eztzを使用して生のrpc呼び出しを送信できると思います:
eztz.node.query("/chains/main/blocks/head/operations").then(function(res){ console.log(res); }).catch(function(e){});
/chains/main/blocks/head/operations
head
とも呼ばれる最新のブロックに含まれる操作のリストを提供します.このRPCエンドポイントの詳細な説明はここにあります. したがって、完全な解決策は、特定の時間枠内で、操作のレシートが見つかるまで、setIntervalサイクルでこのエンドポイントを「ポーリング」することです.
例:次の
1 minute
でRPCエンドポイントを呼び出し、operation id
に一致するレシートが見つかった場合、操作は正常に含まれていると結論付けることができます.代替の
tezos-client
コマンドは次のようになります.tezos-client wait for <operation hash> to be included
I think you could send a raw rpc call using eztz:
eztz.node.query("/chains/main/blocks/head/operations").then(function(res){ console.log(res); }).catch(function(e){});
/chains/main/blocks/head/operations
Gives you a list of operations included in the latest block also known ashead
. You can find a detailed explanation of this RPC endpoint here.So the full solution could be, that you 'poll' this endpoint in a setInterval cycle, until you find a receipt for your operation, within a certain time frame.
E.g. in the next
1 minute
, call the RPC endpoint, and if a receipt matching myoperation id
is found, we can conclude that the operation was included successfully.Alternative
tezos-client
command would be:tezos-client wait for <operation hash> to be included
-
操作が最新のブロックで行われることが保証されていないため、このソリューションは一般的に堅牢ではないと思います.後続のブロックにある可能性があり、ノード全体にトランザクションインデックスがないため、実際にはその方法で適切な情報を取得できない場合があります.OPは、独自のtxデータベースを構築するか、TzScanやConseilなどの既存のデータベースに依存する必要があると思います.I believe this solution is not robust in general because you are not guaranteed that the operation will be in the latest block. It could be in a subsequent block and because the full node does not have the transaction index you may find yourself unable to actually get the proper info that way. I believe OP should either build his own tx database or rely on an existing one like TzScan or Conseil.
- 0
- 2019-02-06
- Ezy
-
`tezos-client`がこれをどの程度正確に実装したかはわかりませんが、tzscanのAPIを使用するのが1つの方法です.しかし、ポーリングを開始すると、eztzを使用して操作を注入する前に、ベイク時間が速すぎるか、料金が低くて操作が単純に行われない場合を除いて、操作が含まれるブロックを確実にキャッチできると思いますすぐに含まれます-私は実際には起こらないと思います.I'm not sure how exactly has `tezos-client` implemented this, but using tzscan's api is one way. But i think if you start polling, before using eztz to inject an operation, you will certainly catch the block where the operation will be included, unless the baking time is too quick, or your fees are low and the operation simply won't be included anytime soon - which i don't think really happens.
- 0
- 2019-02-06
- Matej maht0rz Šima
-
また、eztz.contract.sendを呼び出すと、[このrpcエンドポイント](http://tezos.gitlab.io/mainnet/api/rpc.html#post-injection-operation)へのPOST呼び出しが発生します.私の理解では、生のRPCを使用する場合、最善の策は、次のブロック/新しいヘッドを調べて、操作IDを探すことです.Also calling eztz.contract.send, results into a POST call to [this rpc endpoint](http://tezos.gitlab.io/mainnet/api/rpc.html#post-injection-operation). In my understanding, using raw RPC, your best bet is to look at the upcoming blocks / new heads, to look for your operation id.
- 0
- 2019-02-06
- Matej maht0rz Šima
-
Tezosクライアントは、操作が受け入れられるかタイムアウトになるまでブロックします.アプリのOPがブロックを書き込んでいて、短い間隔でポーリングするのは堅牢な方法ではありません.理想的には、txが受け入れられたという通知を受け取りたいのですが、eztzは私が信じていることをサポートしていません.したがって、より遅い頻度でインデックスを作成する必要があるか、モバイルアプリを実行する場合は適切ではないローカルノードを使用する必要がありますTezos client blocks until it has the operation accepted or times out. You do not want the app OP is writing blocking and polling at quick interval is not a robust way. Ideally you would like to receive a notification that the tx was accepted but eztz does not support that i believe. So either you need to ask an index on a slower frequency or you need to use a local node which is not good if you want to do a mobile app
- 1
- 2019-02-06
- Ezy
-
作成者が何を達成したいかによって異なりますが、エントリポイントが実行された後にコントラクトの新しいストレージ値を取得しようとしている場合、eztzはコントラクトのストレージも監視する方法を提供します.Depends on what the author wants to achieve, if he's looking to get new storage values for the contract after an entry point was executed - eztz provides a method to watch the contract's storage as well.
- 1
- 2019-02-06
- Matej maht0rz Šima
-
簡単に感謝します!「eztz.contract.sendも呼び出すと、このrpcエンドポイントへのPOST呼び出しになります.私の理解では、生のRPCを使用して、次のブロック/新しいヘッドを調べ、操作IDを探すのが最善の策です」いい答えです. チェックユニットをリクエストし、ない場合は前のブロックを見ていきます!Easy thanks! "Also calling eztz.contract.send, results into a POST call to this rpc endpoint. In my understanding, using raw RPC, your best bet is to look at the upcoming blocks / new heads, to look for your operation id" it is good answer. I will request a checking unit and if there isn’t there, I’ll watch the previous blocks!
- 1
- 2019-02-07
- Михаил Магомедов
-
現在のヘッドの操作をポーリングするのは良い方法です.getIntervalを使用して2〜3分間ポーリングし、その後非同期promiseを使用してタイムアウトすることができます.前にポーリングを開始するか、現在のヘッドハッシュ/レベルを記録することをお勧めします.また、スキップされたブロックレベルを正しく処理するためのコードが含まれていることを確認する必要があります.間もなくeztzに「opが含まれるのを待つ」を追加しますPolling the operations of the current head is a good way, you can poll for say 2-3 minutes using getInterval and timeout after that using async promises. You would be best to start polling before, or recording the current head hash/level. You would also need to ensure code is included to correctly handle skipped block levels. I'll be adding the "wait for op inclusion" into eztz shortly
- 0
- 2019-02-07
- Stephen Andrews
-
- 2019-02-06
つまり、トランザクションはalphanetに投稿されました. TzScan(
ooTC8mMZ7dG1ReCXLPiTAN3qEUB7uNFuh9R8KZXEFbZZiZcypBf
の下)で操作alphanet
を検索すると、ここトランザクションハッシュとブロックハッシュを使用
BMWZp5qBho1V62bb9necMuSuEa結果の詳細を取得する この他の
>回答に示されている手順に従って、必要な詳細を取得することをお勧めします. コードから何かをしたい場合は、TzScanAPIを介して呼び出すことができるはずです
https://api6.tzscan.io/v3/operation/oogKXTkRmJLBmnB
ただし、この呼び出しはアルファネットでは機能しないようです.この
質問で、それが予想されることかどうかを尋ねましたが、メインネットの場合はそうする必要がありますわかりました. [編集]実際、他の質問に対する答えは、alphanetのクエリに別のサーバーを使用する必要があるということです. ophashを使用すると、このコマンドでブロック情報を取得できます
So your transaction was posted in alphanet. If you search for operation
ooTC8mMZ7dG1ReCXLPiTAN3qEUB7uNFuh9R8KZXEFbZZiZcypBf
in TzScan (underalphanet
) it is displayed hereWith the transaction hash and block hash BMWZp5qBho1V62bb9necMuSuEaV5vm1G4Zu7mEQ7y8eaATHAfuB which contains your transaction you can follow the steps here to get the details about the outcome
I would recommend following the steps indicated in this other answer to get the details you want.
If you want to do things from code you should be able to call into the TzScan API through
https://api6.tzscan.io/v3/operation/oogKXTkRmJLBmnBQgP2My4QKRHAGLez96krSFshhg51hA8GEMVp
However it seems that this call does not work for the alphanet. I asked in this question if that's something to be expected, but for mainnet it should be ok.
[EDIT] Actually the answer to the other question is that you just need to use a different server for the query in alphanet. With your ophash you can get the block info with this command
https://api.alphanet.tzscan.io/v3/operation/ooTC8mMZ7dG1ReCXLPiTAN3qEUB7uNFuh9R8KZXEFbZZiZcypBf
-
eztz自体が呼び出し操作内でブロックを受信するため、ブロックはありません:(I do not have a block, because eztz itself causes a block to be received inside the call operation :(
- 0
- 2019-02-06
- Михаил Магомедов
-
ステップバイステップの詳細を追加しました.あなたは今私が思うに良いはずです!I added step-by-step details now. you should be good now i think!
- 0
- 2019-02-06
- Ezy
-
申し訳ありませんが、この回答はeztzには適していません.これらの操作では、ブロックのIDを知る必要があり、eztzは送信操作後にブロックIDを返しません.Sorry, but this answer is not suitable for eztz, because for these operations you need to know the id of the block, and eztz doesn’t return block id after send operation
- 1
- 2019-02-06
- Михаил Магомедов
-
あなたは私があなたに示したようにtzscanのブロックのIDを持っています.ノードはトランザクションのインデックスを維持しないため、クライアントノードでクエリ(txhash=>blockid)を実行することはできません.トランザクションデータベースが必要であり、tzscanがそれを実行します(またはconseilも同様です).これが明確になることを願っていますyou have the id of the block in tzscan like i showed you. The node does not maintain an index of transactions so you cannot do a query (txhash=>block id) in the client node, you need to have an transaction database and tzscan does that for you (or conseil as well). hope this clarifies
- 0
- 2019-02-06
- Ezy
-
アプリを開発し、jsを使用していますが、ユーザーブラウザからトランザクションを監視する必要がありますI develop app and i use js, and me need watch transaction from user browser
- 0
- 2019-02-06
- Михаил Магомедов
-
httpsクエリをtzscanに送信して、ブロックIDを取得できますyou can send https query to tzscan to get the block id
- 1
- 2019-02-06
- Ezy
-
tzscanは信頼できるソースではなく、いつでも停止できますtzscan is not a reliable source, it can shut off at any time
- 0
- 2019-02-06
- Михаил Магомедов
-
[チャットでこのディスカッションを続けてください](https://chat.stackexchange.com/rooms/89337/discussion-between-ezy-and--).Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/89337/discussion-between-ezy-and--).
- 0
- 2019-02-06
- Ezy
-
これは別のアイデアですが、サードパーティのサービスに要件を追加します.This is another idea, but does add a requirement to a 3rd party service.
- 0
- 2019-02-07
- Stephen Andrews
アプリを開発していて、JavaScriptを使用しています.ユーザーのブラウザからトランザクションを監視する必要があります.トランザクションの作成には、eztzメソッド
eztz.contract.send
を使用します.トランザクションハッシュを受け取りましたが、ブロックIDを返しません.このtxハッシュのトランザクションステータスを知って、トランザクションがネットワークに受け入れられたかどうかを知るための信頼できる方法はありますか?この特定のインスタンスでは、alphanetを使用しており、eztzによって返されるophashは
ooTC8mMZ7dG1ReCXLPiTAN3qEUB7uNFuh9R8KZXEFbZZiZcypBf
です.