test network incorrectly recreates a fabric network when creating a channel #1243

Activity

1. SurbhiAgarwal1 commented on Apr 13, 2026

   

   SurbhiAgarwal1

   on Apr 13, 2026

   Last edited by SurbhiAgarwal1

   More actions

   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
2. wakqasahmed

   added a commit that references this issue on Sep 3, 2026

   Fix createChannel wrongly recreating an already-running network

   ...

   de51c29