- update Application section in README
- remove param name in app.go
- add error checks in processor/block.go
- move vars from model to transact logic
- move newAsset to transact
- use ID for well-known initialisms
- move randomelement, randomnint and differentelement to transact
- remove AssertDefined
- blockTxIdsJoinedByComma: use standard library to join elements
- return nil, instead of []byte{}
- remove go routine in listen.go
- move cache to parser
- inline processor in listen.go
- move store to main package
- move util to main package
- fixed failing cache issue
- fixed staticcheck issues
- removed cache function, implemented caching in the structs and methods
Signed-off-by: Stanislav Jakuschevskij <stas@two-giants.com>
Starting from the processor.Block.Process all methods now return errors
if something goes wrong with unpacking of the blocks and reading the
transactions. In each function where the error is being propagated back
to client it is wrapped in a message with the function name. This makes
it easier to track down the error and see the propagation chain. Finally
the error is logged to the terminal and the go routine shuts down
gracefully. The graceful shutdown executes all deferred functions which
close the context, the checkpointer and the gateway.
Before panics were used everywhere which was an issue because the
unpacking of the blocks happened in a go routine. When a panic happens
in a go routine only the deferred functions of the go routine are called
but not those of the client which lead to unexpected behavior.
The transact function is also executed in a go routine therefore the
same typo of error handling was implemented there.
Signed-off-by: Stanislav Jakuschevskij <stas@two-giants.com>
Before all transactions were processed and when the failure was
simulated a message was printed and all the transactions still
processed. Now the store returns an error when the failure is simulated
which the listener expects so that it can gracefully shutdown the system
and close the context. The context must be closed correctly or the
checkpointer won't save the last processed transactionId to the file
system.
Signed-off-by: Stanislav Jakuschevskij <stas@two-giants.com>
Every struct was put in its own file. Every method which is not used
outside the parser package was given package scope. All interfaces were
removed, they are implemented by the structs which are now used
everywhere needed as return values. There is no clear benefit of using
interfaces in this sample.
Signed-off-by: Stanislav Jakuschevskij <stas@two-giants.com>
Before when pressing 'ctrl+c' and stopping the go program non of the
deferred functions in listen.go were called. A standard procedure for
stopping goroutines with context was implemented which shuts down the
program gracefully. Logs were added to notify the user that the shutdown
was successful.
Signed-off-by: Stanislav Jakuschevskij <stas@two-giants.com>
Created packages for the flat file store and the processor and moved
functions, variables and constants from listener.go to those packages.
Encapsulated everything not used outside the packages, introduced
model.go files which later might be extracted into a model package and
renamed parser/parsedBlock.go to parser/block.go.
Signed-off-by: Stanislav Jakuschevskij <stas@two-giants.com>
Added caching util function with tests and applied in:
- parser.Block.Transactions(),
- parser.Payload.ChannelHeader(),
- parser.Payload.SignatureHeader(),
- parser.NamespaceReadWriteSet.ReadWriteSet(),
- parser.EndorserTransaction.ReadWriteSets(),
methods, as it was in the typescript sample.
Corrected Println usage and added comments to util functions.
Signed-off-by: Stanislav Jakuschevskij <stas@two-giants.com>
Persisting ledger writes to the file system into the store.log file in
the application-go directory. The write values are converted from bytes
to a string when the read write sets are unwrapped in the transaction
processor.
Signed-off-by: Stanislav Jakuschevskij <stas@two-giants.com>
Added block processor struct and the process method.
Implemented getting valid transactions from the last processed index.
Added data structures needed for the store.
Decomposed the parser.Block.Transactions() method into readable chunks.
Added transaction processor struct and process method. Unwrapping
read write set data from the transaction, mapping to a new "write"
data structure and passing down to the store.
Store is an empty function and will be implemented next.
Signed-off-by: Stanislav Jakuschevskij <stas@two-giants.com>
Removed Block and Transaction interfaces and unused statusCode function.
Using the struct instead of the interfaces now.
Signed-off-by: Stanislav Jakuschevskij <stas@two-giants.com>
Created parser, contract and utils packages and extracted each piece of
functionality into its own files. Removed "Get" prefix from methods and
changed return values from interfaces to structs.
Signed-off-by: Stanislav Jakuschevskij <stas@two-giants.com>
Created project structure, fixed typos. Implemented connect.go and
getAllAssets.go. The latter uses an assetTransferBasic struct which
provides a simple API for basic asset operations like create, transfer,
etc.
Added transact.go with some util functions. Using google uuid package to
generate random UUIDs for the transactions.
Implemented pretty printing of JSON results.
Implemented app.go entry point with error handling. The existing
commands are getAllAssets, transact and listen. They can be called from
the command line via: "go run . <command> <command> ...". They will be
executed in order and if a command is not known an the application
panics and aborts before executing any of the commands.
Implementing listen.go. Added checkpointer, context setups, call to
BlockEvents and all the interfaces needed for parsing. Started
implementing the interfaces needed to represent a block bottom up in
structs. Finished NamespaceReadWriteSet, ReadWriteSet and
EndorserTransaction.
Signed-off-by: Stanislav Jakuschevskij <stas@two-giants.com>
By default, Docker images are referenced from Docker Hub. This has now
applied rate limiting that is causing builds to fail. Current Fabric
v2.5 and chaincode container Docker images are also published to GitHub
Container Registry, which does not impose rate limits and will be
located closer to the GitHub Actions runners.
This change:
- Updates to latest Fabric component versions, which are available in
GHCR. The Fabric install script defaults to GHCR as the Docker
registry for versions that are available here.
- Pulls and re-tags chaincode container images from GHCR in advance of
running tests in the build. This avoids them being pulled from Docker
Hub during test execution.
Signed-off-by: Mark S. Lewis <Mark.S.Lewis@outlook.com>
If CA server hasn't finished initialization then the initial register and enroll requests will fail.
Instead of waiting 3 seconds, actually check if CA service is ready.
Signed-off-by: David Enyeart <enyeart@us.ibm.com>
If CA server hasn't finished initialization then the initial
register and enroll requests will fail.
Waiting 3 seconds resolves the issue.
Signed-off-by: David Enyeart <enyeart@us.ibm.com>
Fix test-network-nano-bash orderer4 enrollment.
Also improve error handling and messages in CA interaction.
Signed-off-by: David Enyeart <enyeart@us.ibm.com>
test-network-nano-bash is often used with locally built
fabric and fabric-ca binaries.
As such the intent is to first look for locally
built binaries and then fall back to binaries downloaded
with the samples.
This was correct for fabric binaries but not the fabric-ca binaries.
Signed-off-by: David Enyeart <enyeart@us.ibm.com>
This patch adds BFT Orderer testing to the CI workflows.
The following test environments are updated:
- test-network
- test-network-k8s
Signed-off-by: Tatsuya Sato <tatsuya.sato.so@hitachi.com>
This patch adds initial support for BFT orderers in the test-network-k8s.
When `TEST_NETWORK_ORDERER_TYPE` is set to `bft`, the network launches
four orderers configured with SmartBFT.
Signed-off-by: Tatsuya Sato <tatsuya.sato.so@hitachi.com>
The existing orderer configuration file is incompatible with v3.0,
and the v3.0 configuration does not work with v2.5.
To support both versions, configuration settings have been updated to
use environment variables instead of referencing static configuration
files.
Signed-off-by: Tatsuya Sato <tatsuya.sato.so@hitachi.com>
The shadow plugin is now maintained by the GradleUp organization. Change
to use the current plugin ID and latest version.
Signed-off-by: Mark S. Lewis <Mark.S.Lewis@outlook.com>
A behaviour change in microfab means that the orderer endpoint needs to
be explicitly specified when using the peer CLI to submit transactions.
Ideally the microfab environment would not require this but the
documented commands do not currently work without this.
This change updates the full-stack-asset-transfer-guide documentation so
that CLI commands include the orderer endpoint explicitly.
Signed-off-by: Mark S. Lewis <Mark.S.Lewis@outlook.com>
The new microfab release seems to start slower than the previous
release. This might be due to a change from solo to raft consensus. This
causes failures in the full-stack-asset-transfer appdev tests. Chaincode
deployment fails since the channel is not yet available.
Instead of increasing the sleep time after launching microfab, this
change attempts to wait however long is required by looking for the
"Microfab started" message in the container log before proceeding.
The test script is also updated to correctly stop the external chaincode
process when the script exits. Previously the process ID of the npm
command used to lauch the chaincode was captured rather than the actual
chaincode process.
Signed-off-by: Mark S. Lewis <Mark.S.Lewis@outlook.com>
Update maintainers to reflect activty from the past year.
- Retire Josh Kneubuhl, Matthew White, Arnaud Le Hors, Nikhil Gupta.
- Add Mark Lewis
Signed-off-by: David Enyeart <enyeart@us.ibm.com>
This patch updates chaincode container versions to 2.5 in the following
samples:
- test-network-k8s
- full-stack-asset-transfer-guide
Signed-off-by: Tatsuya Sato <tatsuya.sato.so@hitachi.com>
The test-network peer configuration specifies $(TWO_DIGIT_VERSION) as
the tag for the Node and Java chaincode containers. For Fabric v3.0,
this requests fabric-nodeenv:3.0 and fabric-javaenv:3.0 Docker images to
host Node and Java chaincode respectively. These images do not exist,
which causes deployment of Node and Java chaincode to fail when using
Fabric v3.0. Fabric v3.0 continues to use fabric-nodeenv:2.5 and
fabric-javaenv:2.5.
This change updates the test-network peer configuration to explicitly
specify `2.5` as the Node and Java chaincode Docker image tags. This is
(currently) the correct version for both Fabric v2.5 and Fabric v3.0.
Signed-off-by: Mark S. Lewis <Mark.S.Lewis@outlook.com>
Created project directory, app.go and connect.go files. Reused the logic for
connect.go from the events application and added second organization setup.
Implemented private data transaction example in go as described in the main
documentation in "Tutorials/Using Private Data in Fabric".
Updated README.md with the command to run the go application and the script
which runs the application in the Github Actions workflow.
Fixed typos and punctuation in the private data typescript application.
Signed-off-by: Stanislav Jakuschevskij <stas@two-giants.com>
The latest fabric-gateway client API release (v1.7.0) includes the gRPC error
details in the GatewayExcetion stack trace so it is not necessary to
programmatically access them to demonstrate that they are present.
This change updates the asset-transfer-basic/application-gateway-java
sample to simplify the updateNonExistentAsset example method. It also:
- Updates all samples to use the latest fabric-gateway release.
- Adds equivalent Maven POM files for fabric-gateway application samples.
Signed-off-by: Mark S. Lewis <Mark.S.Lewis@outlook.com>
The repository currently uses Go 1.22 to test samples in the automated
build. This change sets the Go version in all go.mod (and go.work) files
to Go 1.22.0, and removes any Go toolchain entries.
Signed-off-by: Mark S. Lewis <Mark.S.Lewis@outlook.com>
For some signing implementations, such as ed25519, a non-default hash
implementation must be specified when creating the Gateway connection in
client applications. Rather than relying on the default hash algorithm,
it is probably good practice in general to specify an algorithm that is
compatible with your signing implementation.
This change explicitly specifies the hash algorithm to raise visibility
of the option to select the hash algorithm.
Signed-off-by: Mark S. Lewis <Mark.S.Lewis@outlook.com>
