namecoin / electrum-nmc

Namecoin port of Electrum Bitcoin client.
https://www.namecoin.org/
MIT License
29 stars 24 forks source link

Checking a name availability ends up with a bug pop up #220

Closed gits7r closed 4 years ago

gits7r commented 4 years ago

However, the blockchain is not still syncing. I mean, I tried with multiple servers which all report current accurate heights. What could be the problem?

Traceback (most recent call last): File "electrum_nmc\electrum\gui\qt\main_window.py", line 3582, in check_name_availability File "electrum_nmc\electrum\gui\qt\main_window.py", line 2106, in File "electrum_nmc\electrum\commands.py", line 146, in _run File "electrum_nmc\electrum\commands.py", line 118, in func_wrapper File "electrum_nmc\electrum\commands.py", line 1120, in name_show File "electrum_nmc\electrum\commands.py", line 1174, in name_show_single_try Exception: The blockchain is still syncing

Electrum version: 3.3.8 Python version: 3.6.8 (tags/v3.6.8:3c6b436a57, Dec 23 2018, 23:31:17) [MSC v.1916 32 bit (Intel)] Operating system: Windows-7-6.1.7601-SP1 Wallet type: standard Locale: en_US

gits7r commented 4 years ago

I have closed the application and started it again (it was the first run time, when I also created a wallet). So I thought closing and re-opening would fix it. However got another bug pop up with this trace back:

Traceback Traceback (most recent call last): File "electrum_nmc\electrum\gui\qt\main_window.py", line 3582, in check_name_availability File "electrum_nmc\electrum\gui\qt\main_window.py", line 2106, in File "electrum_nmc\electrum\commands.py", line 146, in _run File "electrum_nmc\electrum\commands.py", line 118, in func_wrapper File "electrum_nmc\electrum\commands.py", line 1131, in name_show File "electrum_nmc\electrum\commands.py", line 1120, in name_show File "electrum_nmc\electrum\commands.py", line 1138, in name_show_single_try File "electrum_nmc\electrum\network.py", line 316, in run_from_another_thread File "concurrent\futures_base.py", line 432, in result File "concurrent\futures_base.py", line 384, in __get_result File "electrum_nmc\electrum\network.py", line 972, in make_reliable_wrapper electrum.network.BestEffortRequestFailed: no interface to do request on... gave up.

During handling of the above exception, another exception occurred:

Traceback (most recent call last): File "electrum_nmc\electrum\gui\qt\main_window.py", line 3589, in check_name_availability NameError: name 'e' is not defined

Additional information Electrum version: 3.3.8 Python version: 3.6.8 (tags/v3.6.8:3c6b436a57, Dec 23 2018, 23:31:17) [MSC v.1916 32 bit (Intel)] Operating system: Windows-7-6.1.7601-SP1 Wallet type: standard Locale: en_US

JeremyRand commented 4 years ago

Hmm, interesting. I'll see if I can reproduce either of these.

JeremyRand commented 4 years ago

@gits7r Do you have an estimate of how many confirmations the name you tried to check had at that time? This info would help me confirm/refute my hypothesis.

JeremyRand commented 4 years ago

(A block explorer would be able to tell you how many confirmations a given name has.)

gits7r commented 4 years ago

Hi there, Indeed it only happens for certain domain names. Try with d/tor or d/bitcoin.

For others it will tell me that they are already registered, sorry, For new unregistered ones works too.

JeremyRand commented 4 years ago

@gits7r Hmm, I can't reproduce with either of those names, on either 3.3.8 or master. Does this happen with any server or just some of them?

EDIT: Sorry, you already answered that... reading fail on my end. Lemme do some more digging...

JeremyRand commented 4 years ago

I have closed the application and started it again (it was the first run time, when I also created a wallet). So I thought closing and re-opening would fix it. However got another bug pop up with this trace back:

@gits7r I see where this bug is; it was already fixed in master branch (but affects 3.3.8 and probably earlier tags).

JeremyRand commented 4 years ago

@gits7r Mind cherry-picking https://github.com/namecoin/electrum-nmc/pull/221/commits/2a9fe2a2cec106d7143df0522c069f85a024a3db and providing the new error?

JeremyRand commented 4 years ago

Based on IRC discussion it sounds like this was fixed by d50ac4750f2b10c46fca68cf3906dcb9b8d93767. Closing as fixed; let me know if I should re-open it.