hyperledger / hyperledger/fabric-private-chaincode
Migrate FPC internals from fabric-protos-go to fabric-protos-go-apiv2
- Dominant language
- Go
- Stars
- 174
- Forks
- 98
- Avg merge
- 2d 21h
- Merged PRs (30d)
- 1
Description
**Describe the bug**
When running integration tests that combine FPC with FSC (Fabric Smart Client) in the same binary - such as `integration/go_chaincode/echo` and `samples/demos/irb` - the process panics at startup with:
```
panic: proto: message rwset.TxReadWriteSet is already registered
previously from: "github.com/hyperledger/fabric-protos-go/ledger/rwset"
currently from: "github.com/hyperledger/fabric-protos-go-apiv2/ledger/rwset"
See https://protobuf.dev/reference/go/faq#namespace-conflict
```
This is a protobuf namespace conflict caused by two different packages defining the same proto message types being linked into the same binary.
**To Reproduce**
1. Clone the repo and check out main
2. Run the echo FSC integration test:
```
cd integration/go_chaincode
go test -v -failfast ./echo/...
```
3. Or run the IRB demo test:
```
cd samples/demos/irb
go test -v -failfast ./...
```
4. Observe panic: proto: message rwset.TxReadWriteSet is already registered
**Expected behavior**
Tests run without panicking. No duplicate proto message registration occurs.
**Log-files/Screenshots**
Logs
```
panic: proto: message rwset.TxReadWriteSet is already registered
See https://protobuf.dev/reference/go/faq#namespace-conflict
goroutine 1 [running]:
google.golang.org/protobuf/reflect/protoregistry.init.func1({0x2e4d440?, 0x2e4a9e487ed0?}, {0x2e4d440, 0x2e4a9e487ed0})
/home/psychopunk_sage/go/pkg/mod/google.golang.org/protobuf@v1.36.11/reflect/protoregistry/registry.go:56 +0x1e5
google.golang.org/protobuf/reflect/protoregistry.(*Types).register(0x2e4a9e5f6540, {0x2c76dc5, 0x7}, {0x2ea6160, 0x2e4a9e732008}, {0x2c45ae0, 0x2e4a9e697500})
/home/psychopunk_sage/go/pkg/mod/google.golang.org/protobuf@v1.36.11/reflect/protoregistry/registry.go:579 +0x1c6
google.golang.org/protobuf/reflect/protoregistry.(*Types).RegisterMessage(0x2e4a9e5f6540, {0x2e7f950, 0x2e4a9e697500})
/home/psychopunk_sage/go/pkg/mod/google.golang.org/protobuf@v1.36.11/reflect/protoregistry/registry.go:506 +0x11f
github.com/golang/protobuf/proto.RegisterType({0x2e81f30, 0x0?}, {0x2c97186, 0x14})
/home/psychopunk_sage/go/pkg/mod/github.com/golang/protobuf@v1.5.4/proto/registry.go:181 +0x45
github.com/hyperledger/fabric-protos-go/ledger/rwset.init.0()
/home/psychopunk_sage/go/pkg/mod/github.com/hyperledger/fabric-protos-go@v0.3.0/ledger/rwset/rwset.pb.go:353 +0x4b
FAIL github.com/hyperledger/fabric-private-chaincode/integration/go_chaincode/echo 0.019s
? github.com/hyperledger/fabric-private-chaincode/integration/go_chaincode/echo/out/cmd/alice [no test files]
? github.com/hyperledger/fabric-private-chaincode/integration/go_chaincode/echo/out/cmd/bob [no test files]
? github.com/hyperledger/fabric-private-chaincode/integration/go_chaincode/echo/views [no test files]
FAIL
```
**Environment (please complete the following information):**
- OS: Linux (Ubuntu 25.04)
- FPC Version: main (post PR #957)
- Go: 1.22+
- FSC: v0.11.0
**Additional context**
Root cause: Two separate import chains pull in conflicting proto packages into the same binary:
|Chain|Package|
|---|---|
|client_sdk/go/pkg/core/contract → internal/utils| fabric-protos-go (old API) |
|fabric-smart-client/platform/fabric (FSC v0.11.0)| fabric-protos-go-apiv2 (new API) |
Both packages define Fabric proto types (e.g. `rwset.TxReadWriteSet`) under the same proto message names, causing Go's global proto registry to panic.
Temporary workaround (applied in PR #957): `GOLANG_PROTOBUF_REGISTRATION_CONFLICT=warn` is set in the affected Makefiles, which is the officially documented bridge (https://protobuf.dev/reference/go/faq#namespace-conflict) for this migration scenario.
Proper fix: Migrate FPC's internal/utils, client_sdk/go, ercc, and ecc from `github.com/hyperledger/fabric-protos-go` to `github.com/hyperledger/fabric-protos-go-apiv2`. This aligns FPC with FSC v0.11.0+ and eliminates the dual-registration entirely. The migration requires updating all import paths and any proto type assertions across the affected packages.
Contributor guide
Assessment
This issue has not been assessed yet.