"logic eval error: fee too small" when upgrading to latest Reach (f33abc3d)

[lorenzopolidori]

Describe the error

After upgrading to the latest Reach version (hash f33abc3d), when calling an API from a frontend test script, I get a logic eval error: fee too small. The API in the first contract calls an API in a second contract.

To Reproduce

This is the gist with the debug logging: https://gist.github.com/lorenzopolidori/3db245caa9fb01c2e1891921c686a4c7

You can find the full source code of the two contracts here: https://github.com/terragrids/dapp/tree/dev/blockchain

The automated test code that I ran to generate the debug logging is here https://github.com/terragrids/dapp/blob/dev/blockchain/token-market/index.mjs

token-market is the calling contract, solar-power-plant is the called contract.

To reproduce the issue:

1. Compile the first contract here https://github.com/terragrids/dapp/tree/dev/blockchain/solar-power-plant
2. Copy blockchain/solar-power-plant/build/index.main.mjs into ./blockchain/token-market/build
3. Run the test file to reproduce the issue.

Expected behavior

The API should be called without errors as in the previous version of Reach.

Extra information

Reach hash: f33abc3d
Reach stslib: 0.1.11-rc.8

[jeapostrophe]

Algorand does not support composability, so every client needs to know intimate details about servers they call. You have to encode this knowledge in your clients using the .ALGO options to remote calls, such as the fees argument:

https://docs.reach.sh/rsh/consensus/#rsh_REMOTE_FUN

If you compile with debugging on, then you should see a precis that lists the number of fees for each API call. But you can also just increment by one until it works. Different versions of Reach, or slight variations in your code, may cause different costs. Furthermore, if the costs change because of dynamic values, then when Reach simulates your txn, the resources given to it may be wrong when they actually hit the chain.

I'm closing this because it is the expected behavior. However, I am extremely willing to help you figure out what arguments you need to provide to get this program working.

[lorenzopolidori]

Thanks @jeapostrophe! I will continue here for support, please let me know if you prefer to move this conversation to a different channel.

I have compiled the called contract with debugging on and I got this output:

* Step 0, which starts at /app/blockchain/solar-power-plant/index.rsh:45:7:dot.
   + uses 40 bytes of logs.
   + uses 2 log calls.
   + uses 1 inner transaction.
   + uses 2 input transactions.
   + uses 135 of its budget of 700 (565 is left over).
   + costs 3 fees.
 * Step 2, which starts at /app/blockchain/solar-power-plant/index.rsh:50:67:dot.
   + uses 89 bytes of logs.
   + uses 3 log calls.
   + uses 1 inner transaction.
   + uses 1 input transaction.
   + uses 209 of its budget of 700 (491 is left over).
   + costs 2 fees.
 * API api_SolarPowerPlant_decreaseCapacity, which starts at /app/blockchain/solar-power-plant/index.rsh:50:67:application.
   + uses 57 bytes of logs.
   + uses 3 log calls.
   + uses 1 inner transaction.
   + uses 1 input transaction.
   + uses 209 of its budget of 700 (491 is left over).
   + costs 2 fees.
 * API api_SolarPowerPlant_get, which starts at /app/blockchain/solar-power-plant/index.rsh:50:67:application.
   + uses 89 bytes of logs.
   + uses 3 log calls.
   + uses 1 inner transaction.
   + uses 1 input transaction.
   + uses 201 of its budget of 700 (499 is left over).
   + costs 2 fees.
 * API api_SolarPowerPlant_increaseCapacity, which starts at /app/blockchain/solar-power-plant/index.rsh:50:67:application.
   + uses 57 bytes of logs.
   + uses 3 log calls.
   + uses 1 inner transaction.
   + uses 1 input transaction.
   + uses 196 of its budget of 700 (504 is left over).
   + costs 2 fees.
 * API api_SolarPowerPlant_increaseOutput, which starts at /app/blockchain/solar-power-plant/index.rsh:50:67:application.
   + uses 57 bytes of logs.
   + uses 3 log calls.
   + uses 1 inner transaction.
   + uses 1 input transaction.
   + uses 196 of its budget of 700 (504 is left over).
   + costs 2 fees.
 * API api_SolarPowerPlant_setActive, which starts at /app/blockchain/solar-power-plant/index.rsh:50:67:application.
   + uses 57 bytes of logs.
   + uses 3 log calls.
   + uses 1 inner transaction.
   + uses 1 input transaction.
   + uses 183 of its budget of 700 (517 is left over).
   + costs 2 fees.
 * API api_SolarPowerPlant_setCapacity, which starts at /app/blockchain/solar-power-plant/index.rsh:50:67:application.
   + uses 57 bytes of logs.
   + uses 3 log calls.
   + uses 1 inner transaction.
   + uses 1 input transaction.
   + uses 183 of its budget of 700 (517 is left over).
   + costs 2 fees.
 * API api_SolarPowerPlant_setOutput, which starts at /app/blockchain/solar-power-plant/index.rsh:50:67:application.
   + uses 57 bytes of logs.
   + uses 3 log calls.
   + uses 1 inner transaction.
   + uses 1 input transaction.
   + uses 183 of its budget of 700 (517 is left over).
   + costs 2 fees.
 * API api_SolarPowerPlant_setTotal, which starts at /app/blockchain/solar-power-plant/index.rsh:50:67:application.
   + uses 57 bytes of logs.
   + uses 3 log calls.
   + uses 1 inner transaction.
   + uses 1 input transaction.
   + uses 187 of its budget of 700 (513 is left over).
   + costs 2 fees.
 * API api_SolarPowerPlant_stop, which starts at /app/blockchain/solar-power-plant/index.rsh:50:67:application.
   + uses 58 bytes of logs.
   + uses 3 log calls.
   + uses 1 inner transaction.
   + uses 1 input transaction.
   + uses 197 of its budget of 700 (503 is left over).
   + costs 2 fees.
The program is 1399 bytes.

I can see that all API calls cost 2 fees.
So I have updated my calling contract to this:

spp.SolarPowerPlant_increaseCapacity.ALGO({ fees: 2 })(power)
// ...
spp.SolarPowerPlant_increaseOutput.ALGO({ fees: 2 })(power)

The first remote call is called when the calling contract is deployed before the parallelReduce and it seems to be successful. However, the second remote call (which is called from within an API call in the parallelReduce) fails with the following error:

Error: API call failed: {
  "type": "signAndPost",
  "e": {
    "status": 400,
    "response": {
      "message": "TransactionPool.Remember: transaction MHP4CX42NBUPATNJC753CAY27YYOYX5VLGQI2QSHNRGGLRKLS7GQ: logic eval error: assert failed pc=2482. Details: pc=2482, opcodes=intc 6 // 5\n==\nassert\n"
    }
  },
  "es": "Error: Network request error. Received status 400: TransactionPool.Remember: transaction MHP4CX42NBUPATNJC753CAY27YYOYX5VLGQI2QSHNRGGLRKLS7GQ: logic eval error: assert failed pc=2482. Details: pc=2482, opcodes=intc 6 // 5\n==\nassert\n"
}
    at /stdlib/dist/cjs/shared_impl.js:317:34
    at processTicksAndRejections (node:internal/process/task_queues:96:5)

This is the output of the test with debugging on: https://gist.github.com/lorenzopolidori/e46f8191f692d6a100b23ff277c884a4

I have also tried with the following:

spp.SolarPowerPlant_increaseCapacity.ALGO({ fees: 2, apps: [sppContractInfo] })(power)
// ...
spp.SolarPowerPlant_increaseOutput.ALGO({ fees: 2, apps: [sppContractInfo] })(power)

but I got the same error.

Can you please help me to identify what I am missing?

[jeapostrophe]

Some comments as I'm reading...

• This error seems to be just from the CALLING contract, because normally you'll see two pcs
• I think your test cannot work, because both Alice and Bob try to buy, but only one of them can, because after one succeeds sold is true and !withdrawn && !sold = !false && !true = true && false = false, so the loop ends.
• They are just racing and one wins and the other loses

[lorenzopolidori]

both Alice and Bob try to buy, but only one of them.. They are just racing and one wins and the other loses

Yes, that's expected. This is what I have been testing so far, and this test was working before I upgraded reach from 27cb9643 to f33abc3d and stdlib from 0.1.11-rc.7 to 0.1.11-rc.8.

[jeapostrophe]

I don't understand why you think the test is not working then? This error basically says "I expected to be in state 5, but aren't". In a non-race scenario, Reach can detect this before the call, but in this case it was wrong, so you get the raw network error

[lorenzopolidori]

Yes, that's right.
But when I run

REACH_VERSION=27cb9643 ./reach run ./blockchain/token-market

i.e. the previous version, either Alice or Bob manages to buy the token, and the other gets the error above, which is expected since the programme is not in that state anymore. A.interact.onSoldOrWithdrawn() is called when either of them manages to buy the token.

After cleaning, when I run:

REACH_VERSION=f33abc3d ./reach run ./blockchain/token-market

i.e. the latest version, neither of them manage to buy the token, both get the error above when calling the API, and the test gets stuck.
A.interact.onSoldOrWithdrawn() is never called, suggesting nobody managed to stop the parallelReduce.

[jeapostrophe]

Thank you for pushing me on this. I was wrong. This is a problem. I'm in the middle of fixing it

[jeapostrophe]

Okay, I just pushed a fix. It should take about 20m to test and then we'll do a release ASAP. I am sorry for being difficult. The fees thing was a total red herring

[lorenzopolidori]

No problem, thanks for the quick fix!

[jeapostrophe]

It was released yesterday!

[lorenzopolidori]

I confirm my tests work as expected after the latest release, thanks!