You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When content is overtaken at a vanity URL that was previously cached, the new claim information is shown but the content price is not updated. There's a possibility that the content price is now 10 LBC but the app will still show 0. When the content is streamed or downloaded, the user is charged 10LBC unknowingly.
The original issue was first reported in #511 and then was supposed to be fixed in #511 but still continues to occur. Recently we had a user charged 130LBC for lbry://nine because there was a takeover that didn't show the correct price.
This is most likely related to a more complex "when to refresh cached data" discussed here #451 (comment) but I think something needs to be done in the interim to prevent the scenario where users are charged for seemingly free content.
Steps to reproduce
Access claim X (free) on PC1
on PC2, takeover claim X and set a content price
Wait for takeover and re-access the claim on PC1
Notice claim information is updated but the price shows free
@lyoshenka I don't think it's a duplicate.. I was going to mention that on the call but didn't want to prolong the conversation anymore.
This issue is more of a pricing update problem... Someone can overtake a claim and set a high lbc price and the person going to that claim will see the old price (or free).
There's a bit of timing involved, but this has happened in the past and I'm able to reproduce it.
Maybe it has to do more with the general "when do we invalidate cache" issue, not sure. But I was hoping to have a more short term solution which would product users by refreshing the price before purchase or something.
Looks like it was moved to lbry from lbry-app, not sure where it belongs.
@tzarebczan can you reproduce this issue using only lbrynet? I suspect this is a lbry-app issue involving caching, but if you can reproduce it in lbrynet, then this is the appropriate repo.
If you can ever call resolve on a name and get it to show you the wrong price, then we'll need to fix it here. Otherwise the solution may be for the app to call resolve before any credits are spent, just to refresh the cached price. That said, it's always possible that in the time between calling resolve and get, a new block comes in and the content changes. If that's the only way to trigger this, then I'm much less concerned about it.
@lyoshenka - no, the resolve command shows the correct price, but the app does not. @liamcardenas originally moved it from app to the daemon - maybe they also misunderstood the issue.
It's happening to me right now on lbry://seven - someone put the price at 550 LBC but shows free in app.
I'll move this back to the app side.
The text was updated successfully, but these errors were encountered:
This happened to me with lbry://three today. File was listed as free, and it charged me 10 LBC. Did not download. Then the second time I clicked on the link, it changed to a different file, which also did not download. Showed log file to Tom and he confirmed. Here are screenshots:
@liamcardenas commented on Mon Nov 13 2017
@tzarebczan commented on Thu Nov 09 2017
The Issue
When content is overtaken at a vanity URL that was previously cached, the new claim information is shown but the content price is not updated. There's a possibility that the content price is now 10 LBC but the app will still show 0. When the content is streamed or downloaded, the user is charged 10LBC unknowingly.
The original issue was first reported in #511 and then was supposed to be fixed in #511 but still continues to occur. Recently we had a user charged 130LBC for lbry://nine because there was a takeover that didn't show the correct price.
This is most likely related to a more complex "when to refresh cached data" discussed here #451 (comment) but I think something needs to be done in the interim to prevent the scenario where users are charged for seemingly free content.
Steps to reproduce
Claim data:
Claim being shown as free upon re-entering it:
Charged for content upon downloading:
Expected behaviour
Tell us what should happen
Actual behaviour
Tell us what happens instead
System Configuration
Anything Else
Screenshots
@lyoshenka commented on Tue Nov 21 2017
duplicate of #803
@tzarebczan commented on Tue Nov 21 2017
@lyoshenka I don't think it's a duplicate.. I was going to mention that on the call but didn't want to prolong the conversation anymore.
This issue is more of a pricing update problem... Someone can overtake a claim and set a high lbc price and the person going to that claim will see the old price (or free).
There's a bit of timing involved, but this has happened in the past and I'm able to reproduce it.
Maybe it has to do more with the general "when do we invalidate cache" issue, not sure. But I was hoping to have a more short term solution which would product users by refreshing the price before purchase or something.
Looks like it was moved to lbry from lbry-app, not sure where it belongs.
@lyoshenka commented on Tue Nov 21 2017
@tzarebczan can you reproduce this issue using only lbrynet? I suspect this is a lbry-app issue involving caching, but if you can reproduce it in lbrynet, then this is the appropriate repo.
If you can ever call
resolve
on a name and get it to show you the wrong price, then we'll need to fix it here. Otherwise the solution may be for the app to callresolve
before any credits are spent, just to refresh the cached price. That said, it's always possible that in the time between callingresolve
andget
, a new block comes in and the content changes. If that's the only way to trigger this, then I'm much less concerned about it.@tzarebczan commented on Wed Nov 29 2017
@lyoshenka - no, the resolve command shows the correct price, but the app does not. @liamcardenas originally moved it from app to the daemon - maybe they also misunderstood the issue.
It's happening to me right now on lbry://seven - someone put the price at 550 LBC but shows free in app.
I'll move this back to the app side.
The text was updated successfully, but these errors were encountered: