refactor: move batching fallback logic to ChaincodeMessageHandler

[JhaSourav07]

Overview

Following up on the feedback from PR #497 (Issue #453), this PR refactors the Read/Write batching fallback logic.

It moves the Promise.all looping logic out of the ChaincodeStub (the interface) and into the ChaincodeMessageHandler (the engine). This properly separates the concerns and prepares the handler for the upcoming gRPC implementation.

Changes

• handler.js: Added handleGetMultipleStates and handleGetMultiplePrivateData to manage the concurrent handleGetState calls.
• stub.js: Simplified getMultipleStates and getMultiplePrivateData to only handle validation and delegate directly to the handler. Cleaned up the collection string validation as suggested.
• Tests: Updated unit tests in both stub.js and handler.js to maintain 100% coverage.

Note on Phase 3 (gRPC Implementation)

I am ready to implement the actual gRPC batching logic (buffer the writes, and send GET_MULTIPLE_STATES / PUT_STATE_BATCH messages). However, I noticed that the current @hyperledger/fabric-protos dependency (v0.2.2) does not yet include these new v3.1.0 message types.

Should we wait for a fabric-protos bump before implementing the final network layer?

[JhaSourav07]

Hi @bestbeforetoday, I've opened this PR to address your architectural feedback from #497.

I have moved the fallback logic out of the ChaincodeStub and into the ChaincodeMessageHandler as you told , keeping the stub thin.

I was preparing to implement the actual gRPC batching in my this PR, but I noticed that the @hyperledger/fabric-protos dependency is currently on v0.2.2 and it does not seems to include the new v3.1.0 message types (like GET_MULTIPLE_STATES) yet. Let me know if we should wait for a package bump upstream before I tackle the network layer!

[bestbeforetoday]

You can bump the @hyperledger/fabric-protos dependency to 0.3.7. That will contain the required protocol buffer messages, and should be backwards compatible - at least at the network layer - with the current implementation.

[bestbeforetoday]

Thank you for another nice contribution.

Once suggestion for the unit tests going forward... rather than testing that the stub calls the handler and separately testing that the handler has the expected behaviour, you might consider combining these parts into a single test that:

1. Mocks appropriate elements of the handler.
2. Sets the handler in the stub.
3. Makes calls to the (public) stub API.
4. Asserts that the expected results are returned based on the mocking, or that the appropriate calls are made to the mock for operations that return no value.

In summary, drive the public API (as in the stub tests) but mock and assert behaviour on the backing handler. I think it will be less work and provide more thorough end-to-end testing of the implementation.

It is possible to go one step further and mock the underlying gRPC connection to test the entire implementation, but you certainly don't need to go that far, especially as the existing tests don't do that.

[JhaSourav07]

@bestbeforetoday
Thank you so much for the kind words and the detailed feedback!
I'll also go ahead and bump @hyperledger/fabric-protos to 0.3.7 locally so I can start working on that final network layer. Thanks again for the excellent guidance!

[JhaSourav07]

Hey @bestbeforetoday, I tried bumping @hyperledger/fabric-protos to 0.3.7, but every time I run rush update, the monorepo keeps forcing it back down to 0.2.2.

It seems like another package is causing a conflict. What is the standard way to handle a version bump like this across the workspace?

[bestbeforetoday]

It is really important to use Rush to manage dependencies rather than npm or directly modifying the package.json. There is some information on this in CONTRIBUTING.md. Also see the Rush documentation.

For updating the @hyperledger/fabric-protos dependency, I would use:

rush add --package @hyperledger/fabric-protos@~0.3.7 --make-consistent

I have updated the dependencies in PR #503 so this is just for future reference.