Upgrading Reach with long-running contracts

[lorenzopolidori]

I have a Reach program that, once deployed on Algorand, runs a parallelReduce exposing an API to sell an NFT. The program terminates only when the admin stops it, or when another user buys the NFT.

This contract can run for a long time on the consensus network, and the application frontend connects to the API using the compiled backend JavaScript program, which has been compiled with a certain version of Reach.

When I update Reach to a later version, even without making any changes to the smart contract, the backend program is rebuilt and the frontend is going to use the new backend. However, when trying to connect to the API, Reach gives an error because of an incompatible Algorand approval program (verifyContract failed).

What's the best approach to solve this problem? I was thinking about storing the Reach version hash and the respective compiled backend together with the contract ID of a deployed application, although storing all the versions of the compiled backend could be complicated, as it should be fetched dynamically by the frontend when connecting to the contract.

Of course, an other option would be to terminate the old contract using the previous version and redeploy the new version. This is also tricky as in my frontend application I have a rather large number of contracts deployed at any given time, one for each NFT on the market. Also, I have long-running contracts that are keeping and updating the state of the game, so stopping them would require saving the state variables somewhere offchain, and applying the same state to the new version after deployment.

Any help will be appreciated!

[jeapostrophe]

If you are using non-standards functionality, like views and events, then you need to use the exact same Reach version (technically, you need the same backend version, which is an internal number, but it changes a lot). The best way to do that is to compile it once, commit the build file, and then fix the version in your package-lock.json and Dockerfile.

If you are using standards functionality, like API functions, you can replace your calls to Reach functions in the api namespace with direct use of algosdk. But, this is very difficult, because Algorand does not support composable contracts, so you need to study your Reach compilation output to use it effectively.

Eventually, when Algorand does support composability, we expect to make it much easier to use different Reach versions and, for example, "import" a contract spec into the Reach standard library and interact with it using that version's convenience functions.

[jeapostrophe]

Yup

[lorenzopolidori]

However, I get the following error when trying to connect to a backend compiled with an older version of Reach using the latest reach library: "This Reach compiled JavaScript backend does not match the expectations of this Reach standard library: expected 24, but got 23; update your compiler and recompile!".

[jeapostrophe]

Yes, that's what I'm saying when I say "you need to use the exact same Reach version". I misunderstood what you meant by "safe", I was referring to the hypothetical "Eventually, when Algorand does support composability, we expect to make it much easier to use different Reach versions and, for example, "import" a contract spec into the Reach standard library and interact with it using that version's convenience functions."

[lorenzopolidori]

Thanks. The hypothetical scenario will be a life-changer in my case, if that ever happens.

[jeapostrophe]

The most important thing to get there is to add dynamic resources to Algorand :) Right now, Algorand clients need to be able to fully understand all the code they're calling to predict what resources will be used.