-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider dropping unwrap_or(1.0)
from convert_fee_rate
#80
Comments
unwrap_or(1.0) from
convert_fee_rate`unwrap_or(1.0)
from convert_fee_rate
Mhh, one caveat seems to be that Esplora on Signet seems to return |
unwrap_or(1.0)
from convert_fee_rate
unwrap_or(1.0)
from convert_fee_rate
I agree this shouldn't default to 1 sat/vB, it should throw an error so the caller can decide if they want to retry or default to some value. |
Yes, I also agree that this would be the preferable behavior, although want to note that changing it to return an error will let user's fee estimation on Signet fail where it used to work nicely before. So if the change is introduced it would be nice to feature it prominently in the release notes to make users aware of the fix. It might also be worth breaking the API for this to force users to double-check their code. |
Considering that producing a value is contingent on |
Returning |
Currently, when something goes wrong/the corresponding
pair
can't be found,convert_fee_rate
will default to a bogus1.0
fee rate:rust-esplora-client/src/lib.rs
Lines 90 to 94 in 7faab65
This however messes with users' assumptions they depend on receiving a correct fee update (e.g. in Lightning). Rather than returning a (btw. undocumented) default value,
convert_fee_rate
should just error out if something goes wrong, as it's fallible anyways.The text was updated successfully, but these errors were encountered: