-
Notifications
You must be signed in to change notification settings - Fork 4
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
Stuck at block 6709554 when parsing HE chain #26
Comments
That's a new one. I don't think it's related to #25 since the node I'm syncing with that code has made it to |
Probably a node version problem. Will try with 18 to see if that sorts it out. If so, then we might need to bump node min requirement. |
Tested with node v18.16.0, same problem. Looking at the block
EDIT (18/01/2024): The block above is problematic but looking at the HIVE data is not possible to understand why. One will need to look at the HE chain data where the error is coming from. |
Can you try adding a log for |
Is this the same you have:
|
https://he.dtools.dev/b/6709554 yeah looks like the right block. |
Hmm, it should definitely be defined according to what I see in the transaction, can you try logging |
Is it because there is the assumption that each action only has 1 event?
|
Interesting, it looks like there should be at least 2 actions, but you only seem to have 1. Can you grab the entirety of tx |
Its my public node... RPC: he.atexoras.com:2083
|
Hmm, I'm getting the same issue now,
wonder what is causing this and how it worked on one machine, but failed on another. Did you ever get past it @forkyishere? |
Looks like it happens again on block #6709577. |
No, never got passed that, and been relying on other snapshots. I am going to do full syncs this weekend (still on the benchmarks phase) and document if I get still stuck. What version of node? (don't think this has to do with mongo, but I am running 7 now as well on the new env) |
Again @ 9536651 Node @ v18.19.0 and Mongo @ 7 |
Again @ 9536695 |
But wait, you are getting different blocks every time you go again, or you are saying that you found other blocks ahead with the same problem? |
Again @ 13486273 |
Another block ahead with the same issue. I've been skipping these bad blocks for now till I have time to figure out what causes it and fix it(or hopefully someone else fixes it before). |
Yep, just got the same block. So still happening. I am using ubuntu 23.10, mongo 7.0.5 and node v18.19.0. Will try to document the error this week. I think I know what it means, and should not be a concern (just a situation that was not predicted). |
Ok, I think I am on something here. But I might need help with the fix. So, what I have discovered so far is that all these blocks have one (at least for blocks here presented) transaction where in the logs field, there is an error. The transaction usually consists on a buy action of an NFT of the same account (the same that is selling that NFT). The logs field show: That looks like where the error is coming from. Because the transfer actually fails, due to not being able to get agent fees. Next step is to try understand why the parsing of these blocks fail... |
Is it because its expecting an "events" field with another "data" field inside and the first thing that it gets its an "errors" one, which does not have the data field? Example for HE block This would not be a big deal, but it means that the parsing needs to contemplate not just expecting "events" from the "logs" field. If this is correct then the function |
Ok, I think I know what happened. Back then the contract would still allow for the fees event to happen... when someone was trying to buy something they own already. Example: https://he.dtools.dev/tx/824d596fc1692c290d6457a9c16631223261f07a My question here is... did that event of the fees in this transaction really happened? did the user lost those fees? If so, we need to adapt the parsing to intelligently understand what is parsing as an event. The problem specifically on these blocks is on Hence the this line will fail:
I don't know if there are other situations... so I am testing with this (full replay):
There is another file that does not have the protection, over the |
Ok, I have now passed the first block that was problematic. Still going... no errors. |
Hmm did the token transfer actually happen at all? If it did not happen I think the nft-market buy operation could be ignored completely, in case there is an error. But in that case I would say that the hive-engine nodes should not even be logging the token transfer? Maybe that's also a limitation of thive-engine nodes..
|
In this case, I don't think it HAPPENS anymore... but I can't be sure if the past it did happen. And this one is a corner case because the NFT is being bought by the owner itself. So, I don't think there is a record of any transaction. Hence I would default, that it didn't happen at all. But I don't know if I can generalize that for all other combinations of errors. And that's where my lack of understanding goes. I have decided to specifically ignore that event amount combination with NFT purchases only. So far... no errors. But the reality is if there are more "number" of events, that rule does nothing anymore (and we get to the same problem again). Unless indentifying the event type before deciding to parse. Which is my question... is that too costly or simply does not make sense. I am on 23507060 block already... (taking forever...) but no errors. Anyone trying to use the old code, those transactions will not be parsable... and there is a retry and error situation, by stopping and restarting the parsing server, that will roll over them eventually. |
Completed sync without problems. |
Added this to the MR: #32 |
Not related with #25, but since its implementation needed a full replay, when I have attempted a full history rebuild using node version bellow, I can't get past HE block 6709554.
Node: v16.17.1
Mongo: 4.4.21
Ubuntu: 20.04 LTS
The text was updated successfully, but these errors were encountered: