Before this commit, partial results were yielded before we had
examined the whole split configuration.
I think the correct behaviour is to create all the routes for the
current configuration, then to yield them. If there is an exception,
we should try the next one.
Upon receiving UNKNOWN_NEXT_PEER, TEMPORARY_NODE_FAILURE
or TEMPORARY_CHANNEL_FAILURE, remember the trampoline route
that was used, and try other routes before raising the
trampoline fee.
Before this commit, we used to raise the trampoline fee
upon receiving any error message, in order to ensure
termination of the payment loop.
Note that we will still retry failing routes after we have
raised the trampoline fee. This choice is questionable, it
is unclear if doing so significantly increases the probability
of success.
Tests: add a test for trampoline handling of UNKNOWN_NEXT_PEER
(This was added in 3a7f5373ac. Not sure what the reason is, but
it triggers UNKNOWN_NEXT_PEER errors, that in turn affect routing
choices, e.g. fallback to single trampoline route)
Replace get_key_for_outgoing_invoice, get_key_for_incoming_request
with Invoice.get_id()
When a new request is created, reuse addresses of expired requests (fixes#7927)
The API is changed for the following commands:
get_request, get_invoice,
list_requests, list_invoices,
delete_request, delete_invoice
`wallet.make_unsigned_transaction` can raise NotEnoughFunds or NoDynamicFeeEstimates.
These are "expected" exceptions that need to be handled or worked around. Added a note
of this in the docstring now.
We now handle NoDynamicFeeEstimates by allowing a static fallback fee in
`wallet.can_pay_onchain` and `lnworker.suggest_funding_amount`. It should be
fine to have a static fallback in these cases, as the user still has a chance
to set their own fee later in the flow.
(though ofc the static fallback might be too high in some mempool conditions,
in which case e.g. can_pay_onchain might return a false-negative, but this
is still an improvement over raising I believe)
fixes https://github.com/spesmilo/electrum/issues/5784
based on 907e5e7009
This way users get more feedback from the OS when they attempt to launch the app on old macOS.
Co-authored-by: Calin Culianu <calin.culianu@gmail.com>
note: newer versions of pyinstaller (4.4+ ?) want to sign the bundle
themselves, in which case modifying the Info.plist file after
pyinstaller returns invalidates the sig.
fixes https://github.com/spesmilo/electrum/issues/7952
see in particular https://github.com/spesmilo/electrum/issues/7952#issuecomment-1227225602
> So the issue is with the aiorpcx monkey patch in util.py, as it
> relies on side-effecting the asyncio.Task, and it patches Task.cancel.
> However, aiohttp also uses Task.cancel for its own timeouting of the
> http request, with the same Task object, and this confuses timeout_after.
> Ultimately FxThread.run exits.
related https://github.com/kyuupichan/aiorpcX/pull/47
---
note: I am not content at all with this monkey-patching approach,
but at the same time I don't see how to properly fix this handling all
edge-cases in aiorpcx.
python 3.11 is finally adding an implementation of TaskGroup [0] and
an async timeout context manager [1] in the asyncio module of the stdlib.
Looking at the implementations, they look unfeasible to backport:
much of the implementation of asyncio.Task had to be changed for them
to work, and TaskGroup in particular relies on the new ExceptionGroups.
Some of these edge cases we are battling with aiorpcx.curio look
difficult to fix without those stdlib changes...
Anyway, when we bump the min python to 3.11, I look forward to switching
to that code instead, and ripping this stuff out.
[0]: https://docs.python.org/3.11/library/asyncio-task.html#task-groups
[1]: https://docs.python.org/3.11/library/asyncio-task.html#asyncio.timeout
We poll the fx rate provider every 2.5 minutes (unchanged).
Previously if there was any error during a tick, there was no fx rate
available in the client until the next tick.
Now, instead, we keep the last rates received with a 10 minute expiry.
One potential drawback is that previously there was instant feedback
to the user when e.g. changing proxy settings, and this is no longer
the case. E.g. consider a provider that bans Tor exit nodes. If a user
enables using a Tor proxy in the network settings, the fxrate used to
disappear immediately - but now the cached rate would still be
available.
ThomasV
Jamie C. Driver
Sander van Grieken
SomberNight