test network incorrectly recreates a fabric network when creating a channel

[davidkel]

Doing the following

./network.sh up -s couchdb
./network.sh createChannel -c mychannel

results in the fabric network being recreated by the createChannel command using levelDB. The reason for this is due to this check in the createChannel Function of network.sh

 [[ $len -lt 4 ]] || [[ ! -d "organizations/peerOrganizations" ]] && bringUpNetwork="true" || echo "Network Running Already"

as no fabric-tools image now pulled and launched the check that there are less than 4 images running is not correct.

I do have to question as to why does the createChannel attempt to start a network if no network exists ? The paradigm of doing a single action may be better here and just have the up command do it

But as of now it is wrong so a quick fix would be

 [[ $len -lt 3 ]] || [[ ! -d "organizations/peerOrganizations" ]] && bringUpNetwork="true" || echo "Network Running Already"

[SurbhiAgarwal1]

Hi @davidkel , I looked into the logic in createChannel, and the main issue seems to be that the network existence check is relying on an outdated container-count assumption.

Right now, this condition:

[[ $len -lt 4 ]] || [[ ! -d "organizations/peerOrganizations" ]] && bringUpNetwork="true" || echo "Network Running Already"

can incorrectly decide that the network is not running, which causes createChannel to recreate the network with the default database settings. As noted in the issue, this is especially visible after bringing the network up with CouchDB and then running ./network.sh createChannel -c mychannel.

A safer fix would be to stop depending on the number of running containers as the primary signal. Container count is fragile because it changes when images/services are added or removed. Instead, createChannel should check for artifacts that actually indicate an initialized network, such as the generated organization materials or active peer/orderer containers by name. The quick fix suggested in the issue (-lt 3 instead of -lt 4) may solve the immediate regression, but it still keeps the same brittle approach.

A more robust direction would be:

if [[ ! -d "organizations/peerOrganizations" ]] || [[ ! -d "organizations/ordererOrganizations" ]]; then
  bringUpNetwork="true"
else
  echo "Network Running Already"
fi

And if container validation is still needed, it would be better to explicitly check for expected Fabric services rather than a hardcoded total count.

So my proposed fix is:

1. Remove or de-prioritize the hardcoded len threshold check.
2. Use generated crypto/org artifacts as the main network-ready signal.
3. Optionally verify expected peer/orderer containers by name.
4. Keep createChannel focused on channel creation and avoid silently recreating the network unless it is truly missing. This matches the issue’s concern that up and createChannel should have clearer separation of responsibility.

I’d be happy to work on this by first applying the minimal fix for the current regression, and then cleaning up the detection logic so it is less dependent on environment-specific container counts.
test network incorrectly recreates a fabric network when creating a channel