There is gui.stop() already, which does the same thing (which is shared API with kivy).
Also, the _cleanup_before_exit() call was redundant in close(),
aboutToQuit handles that.
related: https://github.com/spesmilo/electrum/issues/6889
This fixes the case where the user quits by pressing Ctrl+C,
and some other minor things.
There is still another issue that sometimes causes a segfault during shutdown...
see #7158
```
$ ./contrib/pull_locale
Found 260 files to translate
Generate template
electrum/gui/qt/installwizard.py:265: warning: Empty msgid. It is reserved by GNU gettext:
gettext("") returns the header entry with
meta information, not the empty string.
electrum/gui/qt/channels_list.py:49: warning: Empty msgid. It is reserved by GNU gettext:
gettext("") returns the header entry with
meta information, not the empty string.
```
E | gui.qt.exception_window.Exception_Hook | exception caught by crash reporter
Traceback (most recent call last):
File "...\electrum\electrum\gui\qt\main_window.py", line 870, in timer_actions
self.update_wallet()
File "...\electrum\electrum\gui\qt\main_window.py", line 1003, in update_wallet
self.update_tabs()
File "...\electrum\electrum\gui\qt\main_window.py", line 1010, in update_tabs
self.history_model.refresh('update_tabs')
File "...\electrum\electrum\util.py", line 412, in <lambda>
return lambda *args, **kw_args: do_profile(args, kw_args)
File "...\electrum\electrum\util.py", line 408, in do_profile
o = func(*args, **kw_args)
File "...\electrum\electrum\gui\qt\history_list.py", line 329, in refresh
self.view.filter()
File "...\electrum\electrum\gui\qt\util.py", line 705, in filter
self.hide_rows()
File "...\electrum\electrum\gui\qt\util.py", line 709, in hide_rows
self.hide_row(row)
File "...\electrum\electrum\gui\qt\util.py", line 685, in hide_row
should_hide = self.should_hide(row_num)
File "...\electrum\electrum\gui\qt\history_list.py", line 445, in should_hide
date = tx_item['date']
KeyError: 'date'
Previously for incoming transports, the diagnostic_name (for log messages)
was just "responder" -- not sufficient to distinguish peers.
We now use the pubkey instead.
For outgoing transports it is f"{host}:{port}" (unchanged).
We could just use the pubkey for both uniformly; but it is quite long, and
it is hard to distinguish them at a glance.
(related to prev commit, but really another bug)
If we had two peers with the same pubkey (peer A in the process of teardown, peer B ~freshly connected),
peer A might remove peer B from lnworker.peers via close_and_cleanup().
rm `close_and_cleanup()` call from reestablish_channel - it was added
as a workaround for this bug (in 8b95b2127d)
before we understood the cause.
If a remote node tries to establish a transport with us but we already
have an open transport with such a node id, there are two sane ways to go, either:
- keep existing transport open, reject new transport
- close existing transport, establish new transport
We could do either; I chose to do the second option here, as that is what
lnd and eclair seem to be doing.
Previously we would get into an inconsistent state: both transports open,
but only one of them stored in lnworker.peers.
SomberNight
ThomasV
bitromortac