search

spydra-tech / fabric-debugger

Extension for Visual Studio Code that makes it easy for developers to build and debug Chaincode right from within the IDE.
Apache License 2.0
14 stars 3 forks source link

How does this plugin work? #318

Closed logres closed 1 month ago

logres commented 1 month ago

Where is the Chaincode Container?

When I started debugging, I noticed that there was no way to locate the chaincode container, even though I had started the Fabric network and installed it. Upon checking the source code of the plugin, I only found some scripts being executed when sending a request, such as "sendTransactionInternal.sh", which contains commands like "peer chaincode $1 -n $2 -C default -o orderer.debugger.com:5050 -c "{\"function\":\"$3\",\"Args\":$4}".

Can someone explain to me where the chaincode is executed? I assume that the chaincode is executed within my VSCode debugger, but I would like to understand how the peer knows to find the chaincode service at a specific port on my host machine.

isCaaS

When I switched to CaaS mode, it appears that the plugin is not functioning properly as I am not receiving any replies to my requests.

ashwath-spdr commented 1 month ago

@logres, you are right in assuming that there is no chaincode container and that the code is running in VSCode debugger.

Regarding how it works, the plugin uses the Hyperledger Fabric dev mode to launch the peer and chaincode. In the dev mode, the peer does not launch the chaincode container, but expects someone else to do it. The chaincode is started by the debugger plugin within VSCode and while doing so, the peer address is provided as an argument to it so that the chaincode connects to the peer's "CHAINCODELISTENADDRESS" and listens for chaincode method invocations so that it can process it and respond. This is the same mechanism for communication between the chaincode and peer if the peer had launched the chaincode container.

Regarding isCaas, this should be set to true only if your chaincode is developed using the new external service model. This basically means that the way you write code to start the chaincode is a bit different. The concept of chaincode as an external service is mentioned here and this is a good example. As you can see from line# 231 onwards, a chaincode server needs to be started. If your chaincode is not written like this, then it will not work if you set isCaas value to true. In this type of chaincode, the plugin uses a fixed port of 5999 where the chaincode server is started (running in VSCode debugger) and the peer sends chaincode method invocation requests to it.

Hope this helps.

logres commented 1 month ago

@ashwath-spdr Thank you for your help.

Your answer really help me understand the working progress of the debugger, but I am still confused by the behavior of dev mode and Caas mode, as in both cases the peer does not manage the chaincode container itself but instead waits for an external service to provide it. The peer just waits at "CHAINCODELISTENADDRESS".

I believe I have received enough hints to search for more details, so I will close this issue and find the answer myself.

Thank you once again for your friendly and prompt assistance.