Add Actions and Reducer production warning.

[ymekuria]

Closes #1013

This PR adds a warning about the current limitation of the o1js reducer api. A note was also added that work is in progress to mitigate the current limitation.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
docs2	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jul 2, 2024 6:31pm

1 Skipped Deployment

Name	Status	Preview	Comments	Updated (UTC)
07-oracles	⬜️ Ignored (Inspect)	Visit Preview		Jul 2, 2024 6:31pm

[mitschabaude]

I'd prefer if this caveat refered to the Reducer API from o1js in particular, and not to the general concept of actions and reducers.

At the protocol level, safe use of actions is very possible, if you implement a better reducer (the upcoming BatchReducer being an example).

Also, we should say why Reducer is not safe to use: Because the reduce() method breaks (completely) if more than a hard-coded number of actions are pending (default: 32).

[ymekuria]

I'd prefer if this caveat refered to the Reducer API from o1js in particular, and not to the general concept of actions and reducers.

Good idea. Do you think this location is still an appropriate place to add the caveat?

Also, we should say why Reducer is not safe to use: Because the reduce() method breaks (completely) if more than a hard-coded number of actions are pending (default: 32).

This was the plan. I was deciding if it made sense to either have a short description in this location with the caveat or to link to a longer description somewhere else, and where a long description would live in the docs if we went that direction.

@mitschabaude I was also working on adding similar warnings to some of the examples in the o1js repo. Maybe it makes sense to add the caveat(temporary until we completely update the reducer) to the o1js reducer doc comments.

[mitschabaude]

Do you think this location is still an appropriate place to add the caveat?

Yes definitely, it's the right place!

This was the plan. I was deciding if it made sense to either have a short description in this location with the caveat or to link to a longer description somewhere else, and where a long description would live in the docs if we went that direction.

Gotcha, both works. A longer description could live as a new "security best practice" (subsection on the zkapp security docs) here: https://docs.minaprotocol.com/zkapps/writing-a-zkapp/introduction-to-zkapps/secure-zkapps#best-practices-for-zkapp-security