@daniel If I submit OTA Keys for 10 nodes, give it time to sync and after a day if resubmit the OTA keys of the same 10 nodes again, will the syncing start again?
What I am trying to ask is, after submitting the OTA keys I could directly check the balance using the getbalancebyprivatekey rpc but instead of doing that if I resubmit the OTA keys will it start syncing from the beginning irrespective of the fact that I did submit them before?
Also, is there an RPC or a method to check the database of all the OTA keys submitted to our full node?
If I can monitor which OTA keys I have already submitted I can avoid resubmitting them
@sid
Does resubmission of OTA keys restart the syncing process?
It depends on whether you chose to reset the data. As explained in this post
if the boolean parameter is set to true, it will tell the remote note to re-start the syncing process. I believe that in your cases, it was set to true, right?
Just set the final param to false. If the key has been submitted before, the next submission with false will fail. Or use the RPC getkeysubmissioninfo supplied with your OTA key to check whether you have submitted the key. Payload should be:
{
"Jsonrpc": "1.0",
"Method": "getkeysubmissioninfo",
"Params": [
"YOUR OTA KEY HERE"
],
"Id": 1
}
1 Like
I used getkeysubmissioninfo to check the status of my OTA key
This OTA i was able to submit it thrice. My flag reset option is always set to false everytime i try to submit an OTA Key. Ideally it should have gave me an error that " OTA key is already submitted" but it didnot. Sometimes it shows the OTA Key already submitted error ,sometimes it doesnt show that error. Is there an issue with the way our fullnode is syncing ?
Basically if i submit an otakey using authorizedsubmitkey, and quickly try to resubmit it it will show me the error “OTAkey already submitted and status =” but once the ota key is synced,if i try to resubmit the ota key after few days it accepts the key without giving the error " OTA already submitted"
Thank you, I’ll look into the issue.
1 Like
Did you restart the full-node after the first submission then made the second one?
1 Like
Hello @daniel , Sorry for the delayed response. No, we didn’t restart the full node.
Here is a detailed view of what is going on:
Let us consider the following OTA Key for reference: 14y3cuaGgYyuAV3BupCevHAm338jzrXdVLnW8nW6sNkdFivnXP2k3otsPgB1co6yQ6vewfXpf5F2tHaGYmQLRdvnxUrYdruwNZ9NXxp
I submitted the OTA Key yesterday with the flag set to false.
I was able to resubmit the same key today with the flag set to false. Please find image below:
Ideally, I should have received an error “OTA key is already submitted” and I shouldn’t be able to resubmit an already submitted OTA key
Please note, I do receive the Error " OTA key already submitted" only if I try to resubmit the key today. As shown in the picture below:
If I try to submit the key tomorrow, I won’t get this error.
Also when I used getkeysubmissioninfo on this OTA key, it displays a result 3. Please find the image below:
We have not restarted the full node and we have checked that our full node is completely synced with the Incognito’s full node. @sid
1 Like
Thank you, I’m looking into the issue.
1 Like
Hi @anirudh.chauhan, @sid,
We have identified and fixed the issues you reported in the following tag. Please update your nodes accordingly and see if the problems still persist. Any feedback or bug reporting is highly appreciated.
Thank you and have a nice day!
4 Likes
Hello @daniel , when you say
Do i have to make changes to the validator code of each of my nodes? Can you please elaborate the changes/updates i need to make at my end so that i can test if the issue is fixed? @sid
1 Like
It has nothing to do with the validator code, the cache layer is an add-on, and only affects nodes running the authorized cache.
If your node is running an authorized cache layer, pull the latest tag and restart your node. Otherwise, the update is not mandatory.
1 Like
Our validator nodes do not have any caching layer. However, our full node does have an authorized cache layer. So then I need to pull the latest tag and restart our full node?
You have pushed the “improve fullnode’s cache layer” changes to the mainnet fullnode? And our fullnode is in complete sync with the mainnet fullnode so these changes won’t get automatically reflected? @sid
Yes, your fullnode only is sufficient.
It’s RECOMMENDED that you re-submit your keys for better result and you don’t need to re-sync your fullnode. Just restart with the latest code.
1 Like
Hi @daniel,
If I restart the full node, it probably won’t take the latest code automatically, right? How do I force it to pull the latest tag? Or is that automated, meaning it does it automatically just with a docker bounce?
Also, this doesn’t need our vnodes to be restarted, correct? I still see 11192021 code for all vnodes, and I am assuming that is going to stay the same?
May I ask whether you deployed your node with docker or with github source code? Can you checkout this commit: https://github.com/incognitochain/incognito-chain/releases/tag/mainnet_20211125_1?
I’ve deployed it with docker, using Rocky’s script where you set the FULLNODE variable to 1.