[feature] APIs which charge should allow price limiting

[happybeing]

There can be large variations between the prices charged for similar operations, including between estimate and execution cost for a given operation.

This makes it necessary for client software to limit what may be deducted from a wallet during any API call that may do this.

This will be especially important during the early phase of a live network where bugs could drain a large sum if limits are not supported, and would be a PR disaster. A recent bug in the transaction code that was paying nodes massive rewards demonstrates that a critical bug could still be present at launch if that goes ahead this October making this kind of check an important safeguard.

The form of this limit may need to be different for different APIs but could include max cost per chunk (or register), and max total cost per call, and preferably both.

[maqi]

due to the recent refactors, consider this as obsoleted.

[happybeing]

@maqi please can you explain how the refactoring addresses or obsoletes this issue.

For example, how can apps deal with this using the API?

Thanks.

[maqi]

the pricing is now to be undertaken by the smart_contract (which has its own check on max_charge), no longer solely depends on the nodes (which was force the client to pay directly).

if you mean: a config to set the max-payout-per-record upload/update (for example, as a parameter of the ClientOperationCfg)
then I think it better to be raised as a separate feature request issue.
Or, you can re-open this issue, if really think it shall be part of the public function API.

[happybeing]

if you mean: a config to set the max-payout-per-record upload/update (for example, as a parameter of the #2657)
then I think it better to be raised as a separate feature request issue.
Or, you can re-open this issue, if really think it shall be part of the public function API.

@maqi I'd like to re-open but don't have permissions to do that!

...because I think this is an app level decision. For example, in some use cases storage will be incidental: ok to fail if deemed too costly and to protect against price spikes or bugs.

This would likely be as much about the user's perception, needs at the time, availability of tokens as anything, so very likely they would want to vary this, or have the app ask what to do depending on costs.

Cost estimates prior to operations may or may not be satisfactory. At the moment they bear little relation to the actual cost, so that would need to improve, but I also think there's a case for apps to be able to set hard limits that cannot be breached, giving user's control of a very important asset - their money!

This is real money and user's will I think want to feel in control, and having wallets drain unexpectedly fast would be a poor UX. We're seeing that when uploads fail at the moment, but few users are trying this so not much has been said.

When uploading is widespread, issues like that will I think get a lot of attention, which will damage reputation of the project or the apps using it.