Then move the error below the loop. The current code flow is very unusual

So this is the value that changes. Is it expected to change in the time the loop iterates with no delay at all ?

Ah because it's a user entry right ?

So this is the actual fix, right ? The retry attempts increment is just a UX improvement ?

Part of a broader software problem in agora management.

Due to number encoding restrictions, agora prices can only be set at certain discrete intervals.

The agora.selectParams function takes user input and shims it into these intervals. Whether or not the actual price of the offer matches the user's desired price is a function of the quantity being sold and the desired sale price.

For now, there is no lib-ready method to "create a partial with a price NO HIGHER THAN x". For a given quantity, a range of user input prices will result in the same output price -- since the available prices are at discrete intervals. So one effective way (used here) is to keep trying with incrementally lower price, until we hit the "next tick lower".

64-bit ints would help here, probably make the problem unnoticeable. In practice, the price deltas from user input -- at high enough quantities -- are small. But, understandably, users really do not like prices to be different from what they input, and the complex technical explanation is unpopular.

No, there is a delay, but in practice 1 attempt and 10 attempts both seem to take a few seconds. selectParams is async because it must ping agora to confirm this offer does not interfere with existing offers; it does this by using a unique locktime.

The number of attempts required to get an offer at "price that is as high as possible but below the prevailing auto-redeem price" is --- given the current design of ecash-agora -- a function of the prevailing redeem price and the quantity being redeemed.

Before bumping retry attempts, users were running into the "Unable to determine FIRMA redemption price" error -- and not really knowing why that error shows up. Apart from the spinner continuing to go, the error makes it look like the service is simply unavailable. So, bumping the retry attempts is the actual fix, in that in practice it prevents the error by allowing more attempts -- which have proved to be necessary for some price/quantity combinations.

From a high level software standpoint, the fix is to improve the ecash-agora lib to get a better way of creating a partial with the price at the "next tick lower." Even without library changes, there is (probably) a way to do this by using the given number resolution constraints to condition the target price we use as a param in generating the partial offer.

The root problem: the lib improvement will be complex and needs some thought (and is possibly not high impact beyond this niche case), while the approach used here rightnow is effective and ready.

sample output

So, another potential improvement here would be to increase NANOSATS_PER_ATOM_REDUCTION_PER_ITERATION

For now though, I think accepting more iterations for the guarantee of not missing the next-lowest available price is an acceptable trade-off.

Could also be more exact if I instead iterate by changing the quantity of atoms listed instead of the price 🤔 -- but this would be an optimization.

In its current form, this diff fixes an issue in prod where users are unable to redeem FIRMA and do not know exactly why. So whatever direction this goes, this diff is an important first step.