-
Notifications
You must be signed in to change notification settings - Fork 101
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Payment state is not PAYMENT_STATE_SENT, got 0 on Polygon. #1224
Comments
@Milerius Could you take a look this or next week? |
Yes |
had another such failed swap on maker side, even after #1716 on both maker and taker
it failed right away, without any retry or so... console on maker looked like this:
and takerpayment (PAXG-PLG20) was fine and mined: https://polygonscan.com/tx/0x6ebd35f3816c5db932d7600534e1b7123c9e76b4a76e8e2940b54bbcd13739aa maybe a retry logic similar to PR 1716 would solve this issue too... though i have no idea what actually happens here |
the consequences of the error from the swap in the last comment are this: maker shows taker has not yet failed swap and shows this in logs:
so the only way for taker to refund the swap is to restart, else it will continue forever |
Yeah, sure. I will work on that. I didn't fix this in #1716 to not do excessive/unnecessary calls until we can be sure that payment state issue was not solved by the PR. It seems that this is another race condition issue where payment state is sometimes updated in RPC node after the transaction is confirmed and returned from |
i got this error again on a PLG20 swap
|
Were you the taker? if not, they might have used an outdated version that uses less confirmations.
Sorry, never mind. Just saw this. |
There seems to be a node with a high weight (11%) that is lagging by more than 20 blocks in this list https://polygon-rpc.com/, maybe this is the problem. |
It's this node, weight is getting reduced for it now. |
I am not sure if such thing should be solved from the API side, but I will look into it in more details this week. Maybe we can retry the payment status call a few times in payment validation stage, but this will not solve very edge cases where multiple nodes are lagging and they are the ones that return the response. |
Yes, could well be. Looks like we need to run our own infrastructure for every chain that we really want to use. The public RPC nodes are unreliable and slow anyway. I see it on my order placing rounds... takes 10 minutes when BEP20 is involved (run by us) and 17 minutes when PLG20 is involved (public crap)... and there are 2 coins in a round, the other one is UTXO... so the public PLG20 are at least half the speed of our BEP20 nodes, likely even slower. |
@cipig can this issue be closed? are you getting anymore of these errors? |
haven't seen this specific error since a longer time https://dexapi.cipig.net/public/error.php?uuid=f691a5f1-e639-47c2-8ec5-cd7bdb224d17 can't find tx the "can't find tx" is mentioned in some other issue... and the "nonce too low" happens when you do more then one swap with same EVM chain at the same time (sometimes... the more swaps, the higher the chance) |
Some PLG20 (Polygon) swap fail
TAKER console:
TAKER swap file/error:
makerpayment from Mar-15-2022 10:36:13 PM +UTC: https://polygonscan.com/tx/0xc472efbec24c3ab7d7e2b91c0b5de4be855f05680fc877c2eabf415e56c4786d
taker failed swap with MakerPaymentValidateFailed on 10:36:47, looks like 30s
we are using https://polygon-rpc.com RPC node
i assume the tx took longer then 30s to propagate/be indexed by the PLG20 RPC node, so my suggestion is to increase the timeout from MakerPaymentWaitConfirmStarted to MakerPaymentValidateFailed to 60s
another such failed swap from today: https://dexapi.cipig.net/public/error.php?uuid=c66b6457-449e-4dda-bc8d-75a50e8ea995
same error,
Payment state is not PAYMENT_STATE_SENT, got 0
EDIT: could the problem be solved by increasing the
required_confirmations
on PLG20 to eg 10?we are currently using this:
btw, this happens sometimes:
15 23:04:57, coins:web3_transport:178] WARN web3_transport:177] Error requesting 'https://polygon-rpc.com/': 60s timeout expired
but idk which API call, mus be setprice, my_balance or get_fee
anyway, just wanted to mention that timeouts on PLG20 RPC nodes are not totally unusual and we should consider it
The text was updated successfully, but these errors were encountered: