- for an onchain backups, if the channel is with a
hardcoded trampoline, try first without gossip DB.
- for imported backups, fallback to gossip DB if we
fail to connect with the provided network address.
As the GUI allows saving such invoices, CLI should not break for these wallets.
Also note the pre-existing assert on the next line.
follow-up bf4455ef30
```
>>> list_invoices()
Traceback (most recent call last):
File "...\electrum\gui\qt\main_window.py", line 1506, in <lambda>
return lambda *args, **kwargs: f(method,
File "...\electrum\commands.py", line 191, in _run
result = fut.result()
File "...\Python310\lib\concurrent\futures\_base.py", line 446, in result
return self.__get_result()
File "...\Python310\lib\concurrent\futures\_base.py", line 391, in __get_result
raise self._exception
File "...\electrum\commands.py", line 154, in func_wrapper
return await func(*args, **kwargs)
File "...\electrum\commands.py", line 1188, in list_invoices
return [wallet.export_invoice(x) for x in l]
File "...\electrum\commands.py", line 1188, in <listcomp>
return [wallet.export_invoice(x) for x in l]
File "...\electrum\wallet.py", line 2405, in export_invoice
amount_sat = int(x.get_amount_sat())
ValueError: invalid literal for int() with base 10: '!'
```
There is some duplication between `wallet.get_onchain_request_status` and `wallet.is_onchain_invoice_paid`
(both in terms of code, and conceptually). `get_onchain_request_status` is used for incoming invoices (receive requests),
and `is_onchain_invoice_paid` is used for outgoing invoices. I think `get_onchain_request_status` existed first,
but as it uses txi/txo, it only works for ismine addresses, so `is_onchain_invoice_paid` was added later
(along with a `get_prevouts_by_scripthash` and corresponding new persisted data structure) to handle the non-ismine
addresses corresponding to outgoing invoices.
I think we could just merge the two functions together... (?)
and this PR does that.
This guards function calls by storing the function, args and kwargs into
an added attribute '__auth_fcall' on the object using the decorator,
then emits a signal that can be handled by the UI.
The UI can signal auth-success or auth-failure back to the object by
calling either the authProceed() slot or the authCancel slot.
The object utilizing this decorator MUST inherit/mixin the AuthMixin
class, which provides the above two slots, and handling of state.
The decorator also accepts a 'reject' parameter, containing the name of
a parameterless function on the object, which is called when
authentication has failed/is cancelled.
