We never really supported pypy - the CI was running the tests there
just to see compatibility.
A few of the unit tests consistently hang, resulting in the whole
test runner timing out and wasting compute resources. Someone could
debug the hangs and try to fix them, but I don't have the time.
ChannelDB.load_data() takes ~15 seconds. Previously if the user tried
to close the program while load_data is running, we would block until
load_data() finished. (e.g. consider starting and immediately stopping
Electrum)
Now instead we can abort load_data early.
Electrum clients that have non-trampoline channels.
- if an invoice supports trampoline, but provides only
non-trampoline nodes in its routing hints, we must use
a legacy trampoline payment
- when we create a trampoline onion for a legacy payment,
the invoice_features field is a u64, so we need to remove
high feature bits.
Plugins.stop() is now part of the normal shutdown flow (since 90f39bce88),
so this shaves up to 100 ms off that (avg: 50 ms).
It is also waited on in around ~60 unit tests: this saves 3 sec.
In python 3.8 and 3.9, asyncio.Event/Lock/etc cannot be created before the
event loop itself is created. Hence, to have Plugins.__init__ create an
Event, we need to postpone creating Plugins() from setUpClass to setUp.
follow-up 90f39bce88
Plugins.stop was never called, so the Plugins thread only stopped
because of the is_running() check in run(), which triggers too late:
the Plugins thread was stopping after the main thread stopped.
E.g. playing around in the qt wizard with wallet creation for a Trezor,
and closing the wizard (only window):
``` 24.85 | E | p/plugin.Plugins |
Traceback (most recent call last):
File "/home/user/wspace/electrum/electrum/util.py", line 386, in run_jobs
job.run()
File "/home/user/wspace/electrum/electrum/plugin.py", line 430, in run
client.timeout(cutoff)
File "/home/user/wspace/electrum/electrum/plugin.py", line 363, in wrapper
return run_in_hwd_thread(partial(func, *args, **kwargs))
File "/home/user/wspace/electrum/electrum/plugin.py", line 355, in run_in_hwd_thread
fut = _hwd_comms_executor.submit(func)
File "/usr/lib/python3.10/concurrent/futures/thread.py", line 167, in submit
raise RuntimeError('cannot schedule new futures after shutdown')
RuntimeError: cannot schedule new futures after shutdown
```
- @amount_msat.validator prevents the creation of invoices with e.g. too large amounts
- however the qml gui is mutating invoices by directly setting the `amount_msat` field,
and it looks like attrs validators only run during init.
We can use `on_setattr` (introduced in attrs==20.1.0).
- a wallet db upgrade is added to rm existing insane invoices
- btw the qml gui was already doing its own input validation on the textedit
(see qeconfig.btcAmountRegex). however that only limits the input to not have more
chars than what is needed to represent 21M BTC (e.g. you can still enter 99M BTC,
which the invoice logic does not tolerate later on - but is normally caught).
fixes https://github.com/spesmilo/electrum/issues/8582
Note: We should probably require the password in load_wallet,
and store it in memory as long as the wallet is loaded. In that
case, commands that currently require a password would no longer
require it if the wallet is loaded.
- when creating an invoice, if we had multiple chans with the same trampoline,
were putting duplicate t-hints into the invoice
- when paying an invoice that had duplicate t-hints, we would sometimes
construct invalid paths (SRC>T1->T1->DST)
follow-up https://github.com/spesmilo/electrum/pull/8536
This replaces 69336befee, which was insufficient.
#8536 added a new field into the struct, which older versions do not ignore but raise:
opening a wallet file with new code updated the struct to include it,
after which old code could no longer open the wallet file.
i.e. #8536 was an invisible wallet upgrade, breaking compat.
This commit simply formalises the wallet upgrade: old code will now show
an understandable error when trying to open new files.
The input_qr_from_screenshot functionality is broken on some Linux machines:
on some machines, `screen.grabWindow(0)` returns an all-black image.
In such cases, instead of telling the user "No QR code was found on the screen",
we will tell them "Failed to take screenshot".
To test:
`QApplication.instance().primaryScreen().grabWindow(0).save("/home/user/wspace/tmp/pic2.png", "png")`
Tested on:
- machine 1:
- ubuntu 22.04, gnome, wayland
- pyqt.version: 5.15.9
- qt.version: 5.15.2
=> gets all-black image for screenshot
- machine 2:
- manjaro, kde, x11
- pyqt.version: 5.15.9
- qt.version: 5.15.8
=> screenshot works
I guess it might be due to x11 vs wayland.
eclair sends CHANNEL_DISABLED if its peer is offline. E.g. we might be
trying to pay a mobile phone with the app closed. In that case we
should not cache the CHANNEL_DISABLED for too long.
LnFeatures.supports() is became part of the hot path of
LNPathFinder.find_path_for_payment()
in 6b43eac6fd,
which made find_path_for_payment considerably slower than before.
It used to take around 0.8 sec originally, then after linked commit went to ~9 sec,
and now this takes it down to ~1.1 sec (on my laptop).
