concordium / concordium-client Goto Github PK

Bug Description

When sending transations via concordium-client, it says "Transaction is finalized into block..." and after that "Waiting for the transaction to be finalized...".

Steps to Reproduce

• Send a transaction, e.g. with concordium client transaction send-gtu --sender b0 --receiver b1 --amount 1

Expected Result
That it wouldn't write "Waiting for transaction to be finalized" when the transaction is already finalized.

Actual Result
An example of the actual outcome:

Transaction '79ef65e338ddb010b50fb75715c0cbfe193c99742a03bb6a3194a7bc404154a5' sent to the baker.
Waiting for the transaction to be committed and finalized.
You may skip this step by interrupting the command using Ctrl-C (pass flag '--no-wait' to do this by default).
The transaction will still get processed and may be queried using
  'concordium-client transaction status 79ef65e338ddb010b50fb75715c0cbfe193c99742a03bb6a3194a7bc404154a5'.
[10:07:12] Waiting for the transaction to be committed...................
Transaction is finalized into block 9fe71d3c61b03545ba5d14dcbc714cee236f8c4980a7c569cc9a3e519e5015aa with status "success" and cost 0.050100 GTU (501 NRG).
[10:07:44] Waiting for the transaction to be finalized...
[10:07:44] Transaction finalized.

Versions

• Software Version: Concordium Client 1.0.1

Bug Description
An error seems to occur on Baker nodes that are running Concordium Client v0.4.11 (testnet) on WIndows OS, when stopped and restarted. This happens when the node is out of sync with the consensus nodes on the chain, and it fails to catch up with them. Running a node from scratch works fine.

This error seems to happen when there is already node data that isn't flushed during the execution of the concordium-client app. Running with or without "--no-block-state-import" produces the same error.

An example of the series of errors is below:
INFO: Consensus layer started
INFO: RPC server started
INFO: Starting out of band catch-up
ERROR: External: Error importing block: OtherError ResultDuplicate
INFO: Starting the P2P layer
INFO: Attempting to bootstrap
INFO: Using bootstrapper 54.77.133.220:8888
INFO: Using bootstrapper 52.17.42.154:8888
INFO: Commencing baking
INFO: Runner: Starting baker thread
ERROR: [sending to x.x.x.x:8888] Connection refused (os error 111)
INFO: Not enough peers - sending GetPeers requests
ERROR: [sending to x.x.x.x:8888] Connection refused (os error 111)
No peers at all - retrying bootstrapping
INFO: Sent a direct message to peer containing a catch-up status message
WARN: Couldn't process a finalization message from peer due to error code InvalidResult
ERROR: [sending to x.x.x.x:8888] Connection refused (os error 111)
WARN: The high priority inbound consensus queue is full!
WARN: The high priority inbound consensus queue is full!

Steps to Reproduce

Expected Result
Once the node is restarted, it catches up with the other nodes in the chain.

Actual Result

Versions

• Software Version is Concordium Client
• OS
• Browser
• Mobile device, if applicable

Concordium-client currently does not retrieve these, so it cannot check that the supplied method is correct.

There are two things here. One is it can use the schema for this, but it can also parse the export list and check directly without the schema.

The main difficulty is a parser for the export section of Wasm, but that again is pretty straightforward.

Task description

In connection with Concordium/concordium-node#236 concordium-client needs to be updated to support V1 contracts.

The high-level requirements are

• concordium-client must still allow to deploy and inspect existing contract types, as well as working with new contracts
• add ability to invoke contracts locally on the node (InvokeContract endpoint)

There should be a general change in handling module deployment. Previously concordium-client added the module version and took just a wasm file as input. In order to reduce errors this should be changed. cargo-concordium will be changed to output a versioned output.

To support deployment of raw Wasm modules we could still support a --version option which would add that version to a raw wasm file before deployment.

Sub-tasks

• Add raw InvokeContract command to invoke the contract for testing
• Add a high-level contract invoke command that requires less input, or more friendly input, from the user
• Allow deploying and inspecting V1 modules analogously as V0 are now. The client should figure out itself which version it retrieved. THe main difference between V0 and V1 modules will be in the module schema. V1 modules will have a different schema, and the semantics of entrypoints will be different, which should be reflected in the the pretty output.

Description
Right now, the characters ", \, tabs and line breaks in memos are displayed as \", \\, \t and \n, respectively.
Suggestion: Those characters could instead be displayed as the actual character (or tab or line break), when the memo is a string, but could be kept as is, if the memo is JSON.

Steps to Reproduce
Send a transfer with memo containing ", \, a tab or a line break.

For example, the memo Hello World is currently displayed as Hello\tWorld in the client.

Versions

• Client Version 1.1.1

We should have the ability to store accounts for multiple chains at the same time in concordium-client.

The client currently supports setting a config directory. We can probably reuse that for this purpose, but make it simpler to use different config directories, and add some warnings/error detection to make sure they are interacting with the right chain.

Task description

Support sending the 3 new transaction types via concordium-client. This should be done by adding an optional "--memo" flag to

• transfers
• scheduled transfers
• encrypted transfers

If the flag is present then the client will make the corresponding transfer with a memo, otherwise it will act as it did before.

To cover the different possibilities I think the following variants of the flag should be present

• --memo takes a string as an argument, and encodes it as a CBOR string in the memo
• --memo-json reads a JSON value from the supplied file and encodes it into CBOR
• --memo-bin takes a file as an argument and includes the contents as a CBOR byte array.

If something else is more convenient or desired then include the description of the options below in the comments.

Related

• https://github.com/Concordium/concordium-node/milestone/1

Sub-tasks

• Add the memo flags as described above.
• The client should check whether the new transactions are supported by the node or not using the node's API. It should fail with a meaningful error when the node does not yet support the given transactions.

Task description
Currently, when running concordium-clien contract show ... the state is only displayed as Null, when there is a schema present, which does not include a schema type for the state.

The expected behavior would be to let the user know, no schema type for the state was found, and then show the state as bytes.

Currently when critical information is overwritten, for example with re-encrypting or when updating keys using writeAccountKeys, a write is performed directly on the keyfile. If this write were to fail for some reason, corrupting the file, then the keys would be lost.

Ideally we should have a more robust system for handling overwriting critical information. Either storing temporary backups of the file before overwriting, then prompting the user to delete them if the overwrite was successful, or performing the write to a temporary file, then if it was successful, renaming it to take the place of the old file.

This should be clearly communicated to the user, so they are aware whether data has been deleted or not, and where to find the temporary backups if they need them.

Task description

When sending transactions it will be useful to support sending with an alias of a sender account.

Subtasks

• We should add a --alias or --subaccount flag as an optional flag to all transaction commands that modify the sender address, the last 3 bytes. The flag should take an integer between 0 and 2^24.
• When registering a baker via an alias the challenge should be computed using the sender address that will be used since that is expected by the chain.

Bug Description
Running concordium-client --grpc-ip localhost --grpc-port 10000 consensus status results in Error: I/O error: Cannot establish connection to GRPC endpoint..

Whereas running concordium-client --grpc-ip 127.0.0.1 --grpc-port 10000 consensus status works just fine.

Other programs work fine with localhost.

⟩ ping -4 localhost
PING  (127.0.0.1) 56(84) bytes of data.
64 バイト応答 送信元 localhost (127.0.0.1): icmp_seq=1 ttl=64 時間=0.021ミリ秒
64 バイト応答 送信元 localhost (127.0.0.1): icmp_seq=2 ttl=64 時間=0.028ミリ秒
64 バイト応答 送信元 localhost (127.0.0.1): icmp_seq=3 ttl=64 時間=0.023ミリ秒

And localhost has been configured correctly in /etc/hosts

⟩ cat /etc/hosts
127.0.0.1 localhost
127.0.0.1 localhost.localdomain
127.0.0.1 local
255.255.255.255 broadcasthost
::1 localhost
::1 ip6-localhost
::1 ip6-loopback
fe80::1%lo0 localhost
ff00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

Steps to Reproduce
Run concordium-client --grpc-ip localhost --grpc-port 10000 consensus status in an Arch Linux installation with a node running on port 10000.

Expected Result
Should output consensus status.

Actual Result
Gives an error.

Versions
concordium-node 1.0.1
concordium-client 1.0.1
Operating System: Arch Linux
Kernel: Linux 5.12.14-arch1-1
Architecture: x86-64

Further details
The node is bound on IPv4 only.

⟩ sudo lsof -i:10000
COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
concordiu 1653 root   30u  IPv4  29462      0t0  TCP *:ndmp (LISTEN)

Running netcat on both localhost and 127.0.0.1 seems to output some data, suggesting that a connection has been established.

⟩ netcat localhost 10000

@^C⏎                                                                                                                                                               

⟩ netcat 127.0.0.1 10000

@^C⏎                                                                                                                                                               

Naturally running netcat on the IPv6 localhost does not work.

⟩ netcat ::1 10000

Further experimentation reveals that by binding the node on the IPv6 localhost by setting Environment=RPC_SERVER_ADDR=::1 makes the command work with localhost.

This makes sense as localhost resolves to both 127.0.0.1 and ::1, but concordium-node is only running on one of these by default.

Maybe the concordium-node should bind to both IPv4 and IPv6 by default, or the concordium-client should be able to handle localhost returning both IPv4 and IPv6 addresses (something which other programs such as netcat seems to be able to do just fine).

When signing transactions make sure that the keys the user has locally, and the threshold, are the same as those on the chain, and warn the user if this is not the case.

We should still allow the user to override the check, in case their node is behind, or because of some other reason that would cause the discrepancy, e.g., the account keys were just updated.

Description
Client should warn when registering as baker with insufficient stake. Right now, the transaction fails eventually without warning. In contrast, when updating stake, it talks a lot about the correct amount etc.

Steps to Reproduce

• register as baker with insufficient stake

Expected Result
Client informs before submitting to chain.

Actual Result
Client does not warn before submitting to chain.

Versions

• CLI 1.1.1-0

Description
When memo text is too long, client should prevent sending transfer. Right now, the transfer is made but will fail. That applies to all three memo transfer types.

Steps to Reproduce

• make a transfer with too long text
• observe failure in cli

Expected Result

• Client should not allow transfer and inform user why.

Actual Result
See screenshot.

Versions

• windows
• client version 1.1.0

Bug Description
When executing the command concordium-client account list , a list of accounts is displayed. 3kKn2kz9YHrkrKUcBZF9NUJbg8LqGzcBbLwzH1VPBdK8hmNqCD Is not in this list, however it is a valid account (https://concordium-explorer.nl/account/3kKn2kz9YHrkrKUcBZF9NUJbg8LqGzcBbLwzH1VPBdK8hmNqCD )

Steps to Reproduce
Do steps above
Expected Result
Account in list

Actual Result
Account not in list.

Versions

• MacOS Monterey 12.1

Bug Description
When trying to use an external host by specifying the grpc port and ip flags, the client gets an error
Although, the command to view account information is successful.

Steps to Reproduce

1. It is enough just to execute the command
   concordium-client consensus show-parameters --include-bakers --grpc-ip 144.76.29.116 --grpc-port 10000
   or this
   concordium-client block show some_block_hash --grpc-ip 144.76.29.116 --grpc-port 10000

2. As I said above, however, we can successfully execute the command to view account information
   concordium-client account show some_address --grpc-ip 144.76.29.116 --grpc-port 10000

Expected Result
Successful command execution

Actual Result
Error: I/O error: gRPC error: not enough bytes.

Versions
testing was carried out on concordiumclient version 3.0.4-0
But also happens on earlier versions of the client.

• Software Version
• OS Windows, Ubuntu (i am sure macos has the same)
• Browser
• Mobile device, if applicable

When a user attempts to add a baker, and sets the stake to higher than their current account balance, the client will give a warning that the transaction will be rejected.

However, if a user sets the stake to less than their current balance, but more than current balance - cost of add-baker transaction, then the add baker transaction will be rejected because the cost of the transaction is first subtracted from account balance, before the node checks that the account balance covers the amount to be staked.

This could be a potentially common occurrence if users simply set stake to their current balance hoping to stake everything.

We should warn users in this situation, (and potentially offer to reduce the amount they are trying to stake by the transaction cost?)

Description

Make register-data behave the same as transfer memos. This means having three ways of providing it, as a string, as JSON, or raw.

I think the best way would be to have three different flags (same as for transfer-memos).

The client should then encode the data as CBOR.

Task description

Add an option to concordium-client either contract show or GetInstanceInfo to output the state of the contract as-is to a file (that is, not as a JSON on hex-encoded string, but the actual state of the contract).

At the moment concordium-client can only send transactions where it signs it with all the necessary keys. As it stands, this negates almost all of the benefits of having multiple signatures.

We should also support the client signing a transaction partially so that keys can be shared on different devices, and a transaction signed on different, independent, devices.

A simple solution can be to simply output a partially signed transaction, and be able to read such a transaction in and attach an additional signature, and send it to the node. The format would ideally be compatible with the desktop wallet proposal format.

Description

When registering as baker via the Windows client with baker add, the baker credential file is not created. However, a bakerID is assigned, the account is marked as baking in the mobile wallet, and the stake is locked (which makes this issue even worse).

The workaround is to manually add the bakerID to the key file and configure the node with that.

Steps to Reproduce

Expected Result
Baker credential file is created.

Actual Result
Baker credential file is not created.

Versions

• Windows client 1.1.1-0
• Windows node 1.1.2

The warning/confirmation for staking >95% of total stake which is present on update-stake is seemingly not present on command to add a new baker.

This is an oversight and should be added.

The following commands have not been implemented, but would be valuable to have in addition to the raw ones.

• node status: Show node state (roles, uptime, number of peers etc.).
• node list-peers: Show list and stats of connected peers of the node.

Bug Description
Trying to register as baker. I used baker generate-keys and then baker add but it is rejected with
Warning: Proof that baker owns relevant private keys is not valid.

Full command was:
baker add stagenet10-baker-keys.json --sender "stagenet10" --stake 14000 --open-delegation-for none --delegation-transaction-fee-commission 5.0e-2 --delegation-baking-commission 5.0e-2 --delegation-finalization-commission 1.0 --baker-url baker-url.json --out stagenet10-baker-credentials.json

Steps to Reproduce

• baker generate-keys
• baker add
  according to documentation + client help that parameters are missing.

Expected Result
Transaction successful.

Actual Result
Transaction rejected with Warning: Proof that baker owns relevant private keys is not valid.

Versions

• concordium-client_4.0.0-delegation-test-0
• Windows

For most commands, if a required parameter is missing, this will be clearly communicated to the user. For example, a transaction send-gtu command with no --receiver parameter will print

Missing: --receiver RECEIVER-ACCOUNT

Usage: concordium-client.exe transaction send-gtu --receiver RECEIVER-ACCOUNT --amount GTU-AMOUNT
                                                  [--sender SENDER] [--keys KEYS] [--signers SIGNERS]
                                                  [--nonce NONCE] [--energy MAX-ENERGY] [--expiry EXPIRY]
                                                  [--no-confirm] [--no-wait]
  Transfer GTU from one account to another.

However for some commands, if the --sender parameter is missing, it will instead try and use a default account, and if this default account is not found, it will throw an error

Account reference not provided; using "default".
Error: The identifier 'default' is neither the address nor the name of an account.

This could be made more informative by also informing the user that the --sender parameter is not set.

Bug Description
Strange warnings in client when restaking as baker:

Steps to Reproduce

• baker update-stake

Expected Result
Warnings without characters in front of type.

Actual Result
See screenshot.

Versions

• Client 1.1.1-0
• Windows node 1.1.2

Bug Description

The client currently immediately queries the transaction after submitting it to the node. This can cause sporadic failure due to data races especially if multiple nodes are behind a load balancer/proxy.

There is no need to query immediately and adding a delay of 2s to the first query would make the behaviour more predictable.

Alternatively we could have a grace counter for errors. Say 5 failed queries (transaction absent) before we declare it truly dead.

Steps to Reproduce

Put two nodes behind a load balancer that routes each request to a different node.

Expected Result

transaction send for a valid transaction leads to "transaction finalized"

Actual Result

transaction send fails with "Transaction was absent".

┆Issue is synchronized with this Jira Task by Unito

We want to avoid calling the Haskell error in any circumstance on the client side, i.e., avoid printouts like
concordium-client: user error ("gRPC error: Consensus didn't accept a transaction via RPC due to Stale")

Description

Since concordium-client is not compatible with node version 1 it would be good user experience if upon establishing the connection the client would request the node version and close the connection in case the version is not at least 1.1.0

This would lead to a better error message for the user. As it is now, the client will fail at some point when it tries to query the node with an ugly parse error.

We currently always provide an energy estimate, but ultimately the cost is paid in GTU, so we should estimate it in that as well.

The wallet-proxy already does this for the mobile wallet, we need to do the same in the command-line.

It should be made clear that these are only estimates since the exchange rate might change by the time the transaction is included.

This is related to #45 since we need the estimates to warn the user.

The script is for connecting a middleware instance to a local docker-compose cluster scripts/bootMiddleware.sh

It uses docker ps --filter "publish=10000"

to fetch the correct containers, but this seems to be relying on a bug that has been fixed somewhere between versions 19.03.8 and 20.10.3.

The problem is that while the container does expose port 10000, it is mapped to 11xxx externally.

bootGHCi and collectLogs scripts have the same issue.

Description
The description for the raw unbannode command asks for you to provide an ip address or port "for the node to ban". This should presumably be "to unban".

unbanNodeCommand :: Mod CommandFields LegacyCmd
unbanNodeCommand =
    command
     "UnbanNode"
    (info
       (UnbanNode <$>
        optional (strOption (long "node-id" <> metavar "NODE-ID" <> help "ID of the node to be unbanned")) <*>
        optional (strOption (long "ip" <> metavar "NODE-IP" <> help "IP of the node to be banned")))
       (progDesc "Unban a node. The node to ban can either be supplied via a node-id or via an IP."))

Description

concordium-client prints schemas in a JSON format, fx when viewing a contract with contract show. This works reasonably well for enum, structs and simple types when they are in the outermost layer. However, lists and complex structures nested in lists are not shown as nicely.

The original intent of displaying the schema as JSON is to aid users of smart contracts with constructing the JSON needed for initializing and updating contracts.

Steps to Reproduce

1. Deploy and initialize a contract with a complex schema, fx
2. View its schema with concordium-client contract show n where n is the contract index.

Expected Result

...
- balanceOf
     {
    "queries": [
      {
        "token_id": ["UInt8"],
        "address": {
          "Enum": [
            {
              "Account": [ 
                    "AccountAddress"
             ]
            },
            {
              "Contract": [ 
                    { "index": "UInt64", "subindex": "UInt64" } 
              ]
            }
          ],
          "callback": { "contract": "String", "func": "String" }
        }
      }
    ]
  }
 - mint
    {
        "tokens": [["UInt8"]],
        "owner": {
            "Enum": [
                {
                    "Account": [
                        "AccountAddress"
                    ]
                },
                {
                    "Contract": [
                        { "index": "UInt64", "subindex": "UInt64' } 
                    ]
                }
            ]
        }
    }
...

The SizeLength of lists, sets, maps (shown as fx One) does not need to be shown, as the length is checked by the client before sending an update to the contract.

Actual Result

...
- balanceOf
    {
        "queries": "List One (Struct (Named [(\"token_id\",List One UInt8),(\"address\",Enum [(\"Account\",Unnamed [AccountAddress]),(\"Contract\",Unnamed [ContractAddress])])]))",
        "callback": "ReceiveName Two"
    }
 - mint
    {
        "tokens": "Set One (List One UInt8)",
        "owner": {
            "Enum": [
                {
                    "Account": [
                        "AccountAddress"
                    ]
                },
                {
                    "Contract": [
                        "ContractAddress"
                    ]
                }
            ]
        }
    }
...

Versions

• Software Version: 1.1.1-0

Task description

Concordium-client supports peerConnect, but not the dual peerdisconnect.

These allow for managing given ("trusted") peers when a node is running so they are useful.

Description
There needs to be an easier way than running a block summary (and digging through that) for a user to find out what the threshold is to become a baker.

When this is made, this issue can be implemented in the documentation: Concordium/concordium.github.io#399

Bug Description
When specifying credential and key indexes to use to sign a transaction with the --signers flag, the client doesn't warn/error if one of the provided indexes is invalid, and instead silently skips that key/signature.

Steps to Reproduce
Try and send a transaction with the --signers flag set to a key that doesn't exist. For example, sending a simple transfer from account account1, where account1 has a single credential with a single key. (At index 0:0)

concordium-client.exe transaction send-gtu --sender account1 --receiver account2 --amount 1 --signers 1:1

Expected Result
The client should identify that the given key does not exist and throw an error

Actual Result
The client fails to find the key, so just skips adding the signature to the transaction, resulting in an NRG cost 100 lower than expected, and the transaction getting sent, then rejected by the baker. (Potentially due to deserialisation failure?)

Note that if you give multiple credentials, fx --signers 0:0,1:0,2:1, then the client will sign with each key which it can find, and skip those it cannot find.

OS: Windows

1. When making an encrypted transfer without having enough money on the general balance, the transaction proceeds with status "pending" and finally fails with status "absent". It would be helpful to show an error message to the user, similar to case 2). The fee is not and cannot be deducted in that case, which might be a risk.

2. When transferring from insufficient encrypted balance, error states "Error: The requested transfer (10000000) is more than the total encrypted balance (3000000)" immediately without spending the user's transaction fee. This is very helpful and does not spend the user's transaction fee.

3. When transferring from insufficient general balance, the transaction is rejected very late in the process after deducting the transaction fee. This could be improved, similar to case 2) . The error message is

    Transaction is committed into block 06cdfccc5b29d54e6847a18f893c4353e18c613b0442297b3d11bab6d006270c with status "rejected" and cost 0.005900 GTU (59 NRG).

    Transaction rejected: insufficient funds.

Description

After updating the smart contract show its state.

In the contract update subcommand make it possible to show the resulting state of the contract, after finalization

As the title states, the only way to currently get chain parameters (e.g., exchange rates) is to use raw GetBlockSummary which is hard to read.

In line with other parameter displays, such as bakers, we should make a nicer interface for getting these.

Bug Description
Currently, when a parameter is missing, the baker configure transaction only shows
Warning: Missing parameters to add new baker.

This is not sufficient, given that there are 18 options in the documentation via baker configure -h, which are not all required.

Expected Result
Similar user guidance as in e.g. baker add.

Actual Result
Warning: Missing parameters to add new baker.

Versions

• concordium-client_4.0.0-delegation-test-1
• Windows

Task description

The GetAccountInfo query allows querying an account either by an address or by a credential registration ID.
The account show command should be updated to allow querying by the latter in addition to the former.

Most confirmation dialogues have the form
Confirm [yN]:
where [yN] indicates the expected user input, as well as default behaviour.

The confirmation dialogue given when a user manually sets --energy on a transaction to lower than the calculated NRG cost is
Do you want to increase the energy allocation to 501 NRG?

This should be changed to be consistent with our other confirmation dialogues.

Task description

The concordium-client application will need to support the new transactions for configure delegation ‘delegator configure' and configure baker ‘baker configure’. They will be similar to the old ‘baker add’ command, but where the arguments are optional for configure.

The old ‘baker add', ‘baker remove', ‘baker set-key’, etc. commands will be changed to use ‘baker configure’ behind the scenes.

The concordium-client will also get new commands ‘delegator add’ and ‘delegator remove’, to add or remove a delegator. These commands will be wrappers around the 'delegator configure’ command.

Bug Description

The query GetBlockSummary fails when blocks are very large. This was first observed on testnet 4 with blocks with the following hashes

eda05241846d608de58497f50f3b96230249fdbb4c6782787d3ed579b62c394e
e397c02598f8a7169874fe38f8790cb091a4d4566ce2f3426259de187f9296f0
04492a870c0ccc541de9dd8652890dd726744c71b518f796618328e1934f2a88
acdfb89dd52dc3144f874a11da1be38b55ed6e508d0543b5dca59b5be5790455
fc5f693b2513c3b741a8320fe948afda7c563a28cfd336572d10262917a5329d
03dba97c6918169b3afc020c57f88d444304eac453189ee522def3418f3eef17
bd2bc466bb71d24839628f48136ee6b12cd532b2472aaefdb2c03f76674952e5
1854afbc16901d0f194c5b1b420bba292334f9db8d13a36f0947f3bc9487c290
d374e0eb6a7d5a66e81209e16392f66e80c55ff459c4dbff8af4767fa0f96703
900074f204c34147bf1f68a91df56f8b9454c02f65164ff177fb7aa5caaec1d6
b041ebe1b38c97b1241b47fecfdfa89ef852c5ed97b44a163c54f7515517fd92
3553e7c22d32ef1d9df3139222475e541650247770e51b97766f2133733de2f2
8a36466c72a3712f3df6bed506f30f6309a60aa051607b97ba98e528c59149e8
752996404a2027654b0e058da367bb1719330ed4993fafc9735a059f42659bd1
fcf3f56af7c6fea9511a3aa3168466001fa8e9196bdfa4bc6bcaa13a0683fbdf
9bba8615c9afe37407fb0b0327f4e322c3175150307026de094090e6b6228eeb
75533215ce2583897cc147be789586dff376de70bf0304178657addb0ea614f8
ca961c381459ffd4eea58bc778546829d832b8fb8f6f857e0d9e0d30ac960853
bd2af80b5d2ee6078a1602827a0f160713f000f967002c0fadbb02ae572b637a
74c5cd2c49e2ae130a4eed9332ba1f8c0dc3da9711bdd549ff9fac3c33a28f95
d00981f4598eef0e3355bbcec1d02c046e8ecd64e2825dfacd962c69bc697ed3

Failure means that the client simply hangs. It does not use any CPU and never terminates.

Steps to Reproduce

Query a very large block. Note that the fact that it is a block summary is irrelevant. The problem is to do with the size of the data that is transmitted over the network, not the kind of data. This is supported by the fact that there is no CPU usage or any activity in the client. The client is just waiting for data.

My conjecture is that there is an accounting bug in the http2 library implementation.

Likely a minimal test case is to make a minimal GRPC server that serves a large string.
Then make a small client using the Haskell GRPC library and make the query. At some size of the string the query is going to just hang.

Expected Result

Query succeeds.

Actual Result

Client hangs.

Versions: All known versions

• OS: At least Windows and Ubuntu.

Task description

The repository README contains a number of obsolete items (e.g., "TPS test") that should be removed.

The entire README needs to be revised and we need to organize it so that it is easier to navigate. At the very least this means

Sub-tasks

• Go through the README and make it reflect reality.
• Add a table of contents, or split the README into multiple files that are linked from README.

It should be possible to get a glance of what the client is, how to build it, and how to contribute to the repository.

Task description

Related to #52 concordium client should display memos for the 3 new transaction types when their status is queried.

This only applies to the transaction status command. The raw GetTransactionStatus will support this by default since it only displays the returned JSON.

The best user experience would be if we try to decode the value as CBOR and if it is

• a number
• a string
• a byte array

then we display it nicely as that, and if it is something more complex we try to decode as JSON, and pretty print that if it is successful, and otherwise fall back to displaying the raw data.

Bug Description

The consensus status command does not always display units. In particular

Slot duration:               250
Epoch duration:              900000

Steps to Reproduce

Query consensus status

Expected Result

Slot duration:               250ms
Epoch duration:              15min

or at least

Slot duration:               250ms
Epoch duration:              900000ms

Actual Result

As described above.

Versions

• Software Version: 1.*

Bug Description
When I try to execute Piggy_bank part 1 smart contract is failed to deploy.
I am using the following command to deploy a smart contract

concordium-client module deploy piggy_bank_part1.wasm --sender

Then it is asking for "Enter password for the credential with index 0 and signing key with index 0:"
soon after I enter the password for index 0 it is showing the following message
"concordium-client: user error (gRPC error: Transaction size exceeds maximum allowed size.)"

Bug Description

Concordium-client allows deploying smart contract modules which are too big to be accepted.

Steps to Reproduce

Try to deploy a .wasm module that is above 65536 bytes.

Expected Result

concordium-client warns or fails saying that the module is too big.

Actual Result

Transaction is sent, and rejected on the chain due to protocol violation.

Versions

• Software Version: 1
• OS: N/A
• Browser: N/A

Task description

I believe concordium-client currently checks for existence of an entrypoint before sending a transaction.
This needs to be revised for V1 contracts so that if a fallback entrypoint exists for the contract any entrypoint is allowed