convert balance to number before saving #105
Labels
No labels
area: devops
area: discovery
area: docs
area: livestream
area: proposal
consider soon
dependencies
Epic
good first issue
hacktoberfest
help wanted
icebox
Invalid
level: 1
level: 2
level: 3
level: 4
needs: exploration
needs: grooming
needs: priority
needs: repro
needs: tech design
on hold
priority: blocker
priority: high
priority: low
priority: medium
resilience
Tom's Wishlist
type: bug
type: discussion
type: improvement
type: new feature
type: refactor
type: task
type: testing
unplanned
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: LBRYCommunity/lbry-redux#105
Loading…
Reference in a new issue
No description provided.
Delete branch "balance"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Any place that checks the balance might be checking against a string currently, this makes sure it is always saved as a number.
Please see my note on floats before merging.
I would advise against any calculations in JS w/ floats.
@ -12,1 +12,3 @@
Lbry.account_balance().then((balance) => {
Lbry.account_balance().then((balanceAsString) => {
const balance = parseFloat(balanceAsString);
I'd use extreme caution with floats, these are not guaranteed to be decimal accurate.
@ -12,1 +12,3 @@
Lbry.account_balance().then((balance) => {
Lbry.account_balance().then((balanceAsString) => {
const balance = parseFloat(balanceAsString);
Recommendations for another approach?
I'm going to strengthen @skhameneh's comment and say storing LBC values as a floating point number should never be done.
Everyone on @lbryio/appsquad needs to be unified on approach here (e.g. always storing deweys so we stay in int land). Please discuss on upcoming meeting or in chat.
@kauffj based on discussion with @skhameneh and @akinwale we plan to continue with this approach (for now), mainly because it is only reverting back to how the code originally worked when the daemon was returning floats pre v0.30 (which seemed to work fine).
We agreed that a better solution would be to convert to deweys and always use those in comparisons, but don't want to introduce a change that big right before two app releases.
@kauffj, @seanyesmunt summarized our discussion well, we talked about filing an issue to resolve concerns while merging this in to move forward for the release. We are not doing any critical operations on the floats at this time and the daemon will further enforce constraints.
I am okay with having this merged in while we take more time to reach a better solution - rather than push invasive, potentially breaking, changes when we're prepping for a release.