Maybe we can disable calling Render as transaction and force everyone to use qrender as a query. Or reroute incoming tx requests to the query execution path when we are able to identify this is a call to Render, but I just took a look at that and it looks messy.

Follow up:
I've been thinking about other use cases of render and am not convinced that Render should not be allowed to change any state. The use case that first comes to mind is the following: There is a web app that pulls data from other sources (realms) and caches it within the local contract on an "as necessary" basis. Another use case is a counter that gets incremented each time the the Render function is invoked -- or any other types of analytics type operations.

So maybe the best solution here is no solution and the take away is don't put anything in your Render function that you wouldn't want someone to call or has potential to be abused in a way that might negatively affect the realm author.

This issue extends beyond the current problem. The code can be executed on Render, which will cause further confusion.

var counter

func Render() string {
	counter++
	return fmt.Sprintf("%d", counter)
}

This will increment the counter before displaying, but the change will not be applied.

I believe the same applies to the banker (incrementation is done in memory but not applied on disk). If it's not the case, then we have a bug.

In my view, the issue is more about ambiguity than performance.

I suggest creating a gno lint formula that generates a warning message when Render modifies data.

I recommend checking out this realm that heavily utilizes Render modification: https://staging.gno.land/r/demo/tamagotchi.

@moul I was just taking a closer look at this. Calling Render via maketx call will in fact change the state of the counter variable in the realm you posted. Calling render via gnoweb uses query vm/qrender under the hood to obtain a vm instance with non-persistent storage.

So do we need to make changes to prevent any Render invocations from changing state or should be make it abundantly clear in the docs that there is no guarantee Render won't change the state.

Is there any action to take or can we close this?

Solution proposed by @moul on our test4 alignment call:

• Possibly rename this to dry-run or something similar and / or
• Render stays as it currently is - it's fine to modify state, we just need to add a disclaimer in the documentation

Moving to Triage until we choose a solution

We're going with option 2: Render stays as it currently is. We just need to add a disclaimer in the documentation.