wallet v3 owner_api "post_tx" seems not work. #470
Comments
|
Is it solved now? I also have the same problem |
|
Just checking through the code, this is a little odd because the code path for post and repost is exactly the same. Are you able to provide debug logs for both node and wallet when this happens? |
|
Can you provide logs from both your wallet and your node? |
|
same code works fine after hard fork ... |
xiaojay
added a commit
to grinfans/Niffler
that referenced
this issue
Jul 21, 2020
|
I have this problem right now, Finalized slate that is being posted making a request to post_tx method. It responds with ( JSON is converted to Python's dics which is why you see I did not see transaction moving to "awaiting confirmation" state, the logs seem to indicate that updater thread is running in the background and I can see tx posting event in the logs but I don't think it has been posted. OS: Wallet version Build at commit Additional info: I merged changes by @pkariz to my master to fix the #635 problem. Possible to re-open this issue? |
|
I also tried with fluffing. Logs do indicate that difference but still no effect. |
|
However if I run cli command logs it does get posted and takes effect. Problem seems to be purely Owner API related. |
|
I was thinking problem could be that it expects transaction and not a slate, so I tried it but it gives |
|
Some additional info: Test performed on: Node version: I examined the node logs and I confirmed that transaction gets pushed to the pool ( I have repeated test to make sure it is pushed to the pool using Owner API and not when I run @yeastplume suggested there is a chance nobody is mining testnet but I created one more tx using CLI and it passed without any problems. Not sure if that is relevant but I also noticed that doing The duplicated entries looked weird so I suspected the transaction could be actually properly broadcasted and appended to the block but maybe for some weird reason wallet does not update its status. I tried to run For now I am out of ideas and how for me to say what else could be relevant but I am available to provide additional information. |
|
Just tested this based on latest master 4c81e4a Note this is a modified main function from 1 recipient wallet listening normally First attempt: posts without issue via the API, transaction appears in stem pool then transaction pool, is mined without issue. Going to also try posting directly from the send function Couple things to note:
|
|
Tried thusly, with inconsistent results. Appeared to work a couple of times, didn't work at least once. I'm tempted to conclude that most of this odd behavior is down to testnet flakiness. |
MainnetDisclaimerThose are tests run on Mainnet using real GRIN, however wallets were created just for those tests and own only negligible amount of coins. If you are reading it after the year 2039 and you figure out how to steal those coins based on the information below, please proceed and buy yourself a house on Mars. CLITwo wallets, now (using CLI) let now and and we can quickly check there are Owner APII will repeat same flow using Owner API. Starting Owner APILet us start by running owner API listener on please note the line Producing an invoiceWe make an API request to init_secure_api, open_wallet then finally issue_invoice_tx with params recipients and it responds with following slate which using create_slatepack_message gives following slatepack New logs that appear in the Owner API Paying the invoiceThis I will do on Finalize using Owner APIAs previously we make an API request to init_secure_api, open_wallet then we decode the slate from right after we run tx_lock_outputs provided the above slate and finalize_tx which gives us a new slate Owner API log got following messages in the mean time Posting the transaction using Owner APIAs previously we make an API request to init_secure_api, open_wallet then we run get_stored_tx to fetch the slate Owner API log got following messages in the mean time Check the txs using CLIObserve that
I will wait 20 minutes and run it again. ( poooof ) Ok one more time and I can see in the logs. Which makes me think that probably (1.) there are two entries in Slate from get_stored_tx investigationAs previously we make an API request to init_secure_api, open_wallet then we run get_stored_tx to fetch the slate and that is NOT the slate we obtained from finalize_tx earlier! Post the slate from finalize txI will try to post again using Owner API only this time I will post the slate that we obtained using finalize_tx earlier and not the one provided from get_stored_tx under ID New logs Check the txs using CLI againnow it shows as confirmed! ConclusionThe reason why it was working with CLI and not working with Owner API was that Owner API was not used correctly. The get_stored_tx method provided the tx ID was not providing the slatepack resulting from finalize_tx which eventually was causing incorrect slate being broadcasted using post_tx. I am not sure if that behaviour is correct. Could someone review @yeastplume ? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
grin-wallet v4.0.0, remote node grin v4.0.0
start owner_api with remote node,
Use following wallet v3 owner_api api to finalize and post a received slatepack_message,
use api like this
slate_from_slatepack_message -> finalize_tx -> post_tx,
works fine, get result "{"id":1,"jsonrpc":"2.0","result":{"Ok":null}}" after 'post_tx'.
However the tx never mined into a block.
then use cli 'grin-wallet repost -i id' make it included in a block.
The text was updated successfully, but these errors were encountered: