Idena Web App validation troubleshooting

[rioda-org]

👋 Let's make a guide so people can learn how to troubleshoot their validation

Desktop App troubleshooting is here

General suggestions when using Web App:

• If you are using Windows OS, I recomend you to install free software NetTime which will keep your clock in perfect syncronisation which is important for validation (http://www.timesynctool.com/NetTimeSetup-314.exe)
• Make sure you turn off every other aplication that uses internet
• Do not run Idena Desktop App with node during validation if you have bad internet
• Do not use JavaScript blocking extensions for your browser (NoScript, PrivacyBadger, Ghostery), Brave browser has built in blockers and will cause problem if you don't know how to configure it
• Do not use browser with auto translate option
• Sign in to Web App 6 minutes before validation starts or else you will fail validation with "Late submision" result

Some troubleshooting steps can do only owner of Shared node because he has access to log files. He will need output.log from shared node and access.log from node-proxy.
But you can check on your own if you had problem with sending decryption keys, as explained in the guide later on.

Problem 1: Late submission

This can happen in two cases:

1. Shared node did not send Short answers proof tx

Get Idena address from person, go to Idena explorer and see it's tx's. Find Short answers proof tx.
That is tx that sends not answers, but smaller data about them, their hashes, proof that user has answered flips for short session. That tx needs to be sent and reach more than 50% of mining nodes, so that network knows that a person has finished short session in time.
Notice that explorer shows some timestamp of tx, but it is not relevant. We need to find real time when tx had been sent in node logs output.log file.

Copy the hash of that transaction.

Now open up output.log of your shared node and search it by that tx hash. You will see real time when your shared node had sent this tx. If it's under 13:32:00 UTC, everything is ok. If you can't find this hash, this person did not validate on your shared node.

If you are interested in finding all Short answers proof tx's, search your log for type=5 tx.

2. Decryption keys were not sent on time, before 13:30:30 UTC

Every identity (Newbies and greater) who submitted flips need to send decryption keys before 13:30:30 UTC. Now there are two cases. Someone can have his own node that is running and had sent decryption keys, but in most cases, people are running just Web App and in that case they need to sign in to Web App 5 minutes before validation starts so they can take part in Flip lottery.

Here is example of identity that did not send flip decription keys on time. You can check this out on explorer. People who got his flips, could not answer them.
https://scan.idena.io/flip/bafkreidxue25g26vurgd5nk6lumgmmnxcisyvcobfron6rwvpjbsxw5pla

For shared node operators:
Now, when you have persons address, you can search your output.log to find when did send public key request tx happen. You need to find tx with his address in sender field

INFO [09-01|13:30:01.153] send public key request sender=0x277769D355867867940becD326C969b3a5c04ef6

If this happened in first 30 seconds during short session, before 13:30:30, everything is good as you can see in example above. But if it's sent after and it did not reach more than 50% of network on time, person will have Late submission result.

Now we can investigate access.log to see when did he login to Web App. You can search using his address and it will show you time of his interaction with shared node. If it's after 13:25:00 he was late for Flip lottery. Also there is case where someone can be late but only if he has his own node that is running and it sent decryption keys.

In case where person did login in time but decryption keys were sent late, that can mean that he had really bad connection or slow phone that was struggling.
There are many people who are doing Web App validation on mobile, using 3G mobile internet. It can cause problem if they have bad signal.

[hlolve]

When decryption keys not sent on time, you can also confirm in explorer, going to created flips by that ID for this validation, and will see that, challenged IDs receiving that flip in short, appears as not answered. When validating each IDs receive in short session 6 flips to answer and 2 more as backup, that only are showed in cases like this.

[Marquebi]

Hi, I just tried to validate this afternoon, and it failed. When launching the validation on web app, it was just loading the first two flips forever. I couldn't do anything, always returning to this loading state when relogging or anything else. Thus the validation failed, I've lost my newbie status after 3 weeks running my node without issues. I sent messages on Telegram and sam other people had similar issues. Anything I can do about it plz ? I don't know what to provide to understand what's gone wrong. Thx

[rioda-org]

Hi, it would help out to post:

• which shared node you were connected to?
• which browser you used, any script blocking adons?
• internet connection type?
• desktop/laptop/mobile?
• did you leave your mining node running?

You can also post logs from Web App > Settings > Validation logs Export

[Marquebi]

Hi,

• I was not using any shared node :'(
• I was using Chrome on my desktop with a Wifi connection
• I logged in 7-8 minutes before the validation starts, my node was also starting, maybe in a synchronizing state when I started the validation on the web app ..
• I add addons on my browser to block ads, like AdBlock Plus. I tried to deactivate them on the idena web page, but it didn't help.
  Here are the exported logs :

2021-10-11T13:43:55.830Z - "VALIDATION STARTED!"
2021-10-11T13:43:55.831Z - "sending public flip key"
2021-10-11T13:43:55.831Z - "get identity state"
2021-10-11T13:43:55.832Z - "Start fetching short flips"
2021-10-11T13:43:55.832Z - "Fetching short hashes"
2021-10-11T13:43:55.832Z - "Fetching short flips"
2021-10-11T13:43:55.854Z - "VALIDATION FAILED"

I know there are lots of not recommended things in my procedure, but I thought I would not be blocked on loading images during the whole validation period.
Thanks for your help.

[rioda-org]

From my experience. Running node on Wi-Fi connection causes problems in most cases. If you can connect your PC with LAN cable that would solve 99% problems.

Did you have problems with validation on Desktop app?

Ok, so your web app was connected to your built in node in Desktop App, then we need to look in your node log files, they are here:
%appdata%/idena/node/datadir/logs/output.logs

And please test your internet connection and share result
http://www.dslreports.com/speedtest

[hlolve]

2021-10-11T13:43:55.830Z - "VALIDATION STARTED!"

13:43

13 minutes late

[Marquebi]

Hi, during the last validation some weeks ago, I was not at home so I validated on my mobile browser. Even if I had issues on last steps with key words as the display was bugged on Safari, I passed the validation. So from now, I never tried any validation using the desktop app ...

Here is the report for my internet connection :
http://www.dslreports.com/speedtest/69762209

Next time, I will sure try to use a LAN cable.

Here are the node logs (I removed some logs at the beginning as the file size was 72MB)
output.log
:

[hlolve]

Here are the node logs (I removed some logs at the beginning as the file size was 72MB)
output.log

INFO [10-11|13:32:48.047] Idena node is starting version=0.27.2

Your problem was your node, never was in sync

[Marquebi]

Thanks for your feedback and your time. I thought that connecting 7-8 minutes before validation time would be enough, and that even if syncing terminated just after the validation begins, it would work but it seems not. I thought first as a network issue because the images kept on loading forever, but it was not. Next time, I will ensure that syncing is ok before the validation, and of course use a LAN connection ;)
Thanks all !!

[hlolve]

I thought that connecting 7-8 minutes before validation time would be enough, and that even if syncing terminated just after the validation begins, it would work but it seems not.

Is enough if you are validating on shared public nodes (running all time). If you are using your node is not easy to get in sync on validation day, you need to start your node many hours before validation.