Reducer incorrectly handles maxTransactionsWithActions option when the list of the actions is pre-fetched.

[dfstio]

On the Berkeley testnet, the reducer throws the error in the reducer that uses the maxTransactionsWithActions option, and the number of actions is higher than maxTransactionsWithActions:

2024-02-11T08:48:10.957Z	bdfc6b29-a88d-4ea7-86b0-632db71711d9	INFO	Error in reduce Error: reducer.reduce: Exceeded the maximum number of lists of actions, 3.
Use the optional `maxTransactionsWithActions` argument to increase this number.
    at Object.reduce (o1js/dist/node/index.cjs:22444:15)
    at MapContract.reduce (/var/task/src/external/NameService/mapcontract.js:124:86)
    at MapContract.wrappedMethod (o1js/dist/node/index.cjs:21788:30)
    at /var/task/src/external/NameService/plugin.js:113:27
    at /var/task/node_modules/o1js/dist/node/index.cjs:20452:13
    at Object.runUnchecked (o1js/dist/node/index.cjs:4665:16)
    at createTransaction (o1js/dist/node/index.cjs:20451:20)
    at Object.transaction (o1js/dist/node/index.cjs:20904:16)
    at Object.transaction (o1js/dist/node/index.cjs:20965:27)
    at NameServicePlugin.send (/var/task/src/external/NameService/plugin.js:112:40)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async runStep (/var/task/src/api/step.js:61:22)
    at async step (/var/task/sequencer.js:29:9)

The error throws when

1. the actions are pre-fetched using

await Mina.fetchActions(publicKey, {
        fromActionState,
        endActionState : undefined,
      });

and
2) the number of actions starting at fromActionState is higher than maxTransactionsWithActions.

In case the actions are not pre-fetched, the empty list of actions is being processed as described in #1426

Code:
https://github.com/dfstio/minanft-api/blob/maxTransactionsWithActions/src/external/NameService/mapcontract.ts#L169:

export const BATCH_SIZE = 3;
  
export class MapContract extends SmartContract {
...
 @state(Field) actionState = State<Field>();
...
 @method reduce(
    startActionState: Field,
    endActionState: Field,
    reducerState: ReducerState,
    proof: MapUpdateProof,
    signature: Signature
  ) {
   ...
   
    const pendingActions = this.reducer.getActions({
      fromActionState: actionState,
      endActionState,
    });
    ...
    const { state: newReducerState, actionState: newActionState } =
      this.reducer.reduce(
        pendingActions,
        ReducerState,
        (state: ReducerState, action: MapElement) => {
          return new ReducerState({
            count: state.count.add(Field(1)),
            hash: state.hash.add(action.hash),
          });
        },
        {
          state: elementsState,
          actionState: actionState,
        },
        {
          maxTransactionsWithActions: BATCH_SIZE,
          skipActionStatePrecondition: true,
        }
      );

[mitschabaude]

IIUC, this is exactly the behavior that was intended. Not a bug.

Of course, it's not great to have a hard limit in the number of pending actions that a contract can handle. We're working on that.

[dfstio]

@mitschabaude
But what is the meaning of skipActionStatePrecondition in this case?

On the local blockchain, it works; when I set skipActionStatePrecondition to true, I'm able to send 16 actions to the contract with maxTransactionsWithActions set to 3 and then process all 16 actions by calling reduce 6 times: each time, reduce() processes max 3 actions.
https://github.com/dfstio/merkle-map-demo/blob/endActionState/tests/contract.test.ts

I only experience this issue on the Berkeley testnet.

[mitschabaude]

@mitschabaude But what is the meaning of skipActionStatePrecondition in this case?

On the local blockchain, it works; when I set skipActionStatePrecondition to true, I'm able to send 16 actions to the contract with maxTransactionsWithActions set to 3 and then process all 16 actions by calling reduce 6 times: each time, reduce() processes max 3 actions. https://github.com/dfstio/merkle-map-demo/blob/endActionState/tests/contract.test.ts

I only experience this issue on the Berkeley testnet.

Oh right, that should work on Berkeley as well. Thanks for clarifying

(Should be trivial to fix. Just not throw that deliberate error when skipActionStatePrecondition is true)