concordium / concordium-node-sdk-js Goto Github PK

Task description

We want to remove the duplication of the code for serializing smart contract parameters.

The task would be to replace the implementation of serializeParameters in serializationHelpers (in the common-sdk) with a function that calls down into rust-bindings, which would serialize it using concordium-base.

Depending on the format of the schema required for the rust library, this might make deserialModuleFromBuffer obsolete.

Bug Description
Block summary fails on block containing a scheduled transfer as the amount field is not a big integer, but an array of arrays containing scheduled amounts.

Steps to Reproduce

• Run await client.getBlockSummary('d0d330b424095386b253c8ccd007b366f3d5ec4fa8630c77838d8982c73b4b70');

Expected Result
No error and that the timestamp and the amount are parsed as big ints.

Actual Result
An error is thrown

Description
As explained by CIS2 Standard CIS2 standard should also following CIS0. Which has the function supports. However there is not support for the same function in Cis2Contract class
https://github.com/Concordium/concordium-node-sdk-js/blob/main/packages/common/src/cis2/CIS2Contract.ts

Steps to Reproduce
NA

Expected Result
functions of CIS0 should also be supported.

Actual Result
NA

Versions

• Software Version
  @concordium/web-sdk: 3.5.0

• OS

• Browser

• Mobile device, if applicable

Task description

As the title states, we need to add a method to generate aliases given an address and a counter.

We should also add a function for checking whether addresses point to the same account.

Bug Description
As the usages are highlighted here
https://github.com/Concordium/concordium-node-sdk-js/blob/main/packages/web/example/SendCIS2Transfer.html
https://github.com/Concordium/concordium-node-sdk-js/blob/main/packages/web/example/SendCIS2UpdateOperator.html

The schema returned from contract.createUpdateOperator({energy: 10000n}, update). Cannot be used directly with walletApi.sendTransaction(connectedAccount, type, payload, json, schema) since the types are different. createUpdateOperator method returns a parameter schema.

Steps to Reproduce
execute the example

Expected Result
The schema returned from createUpdateOperator should be directly be usable with ``walletApi.sendTransaction`.

Actual Result
build error

Versions

• Software Version
  @concordium/web-sdk: 3.5.0

• OS

• Browser

• Mobile device, if applicable

Bug Description

As stated, calling serializeUpdateContractParameters with a wrong receiveName returns and empty buffer instead of an error.

Steps to Reproduce

• Call serializeUpdateContractParameters with a receive name that is not included in the schema given to the function

Expected Result

• Throws an error

Actual Result

• Returns empty buffer

Versions

• Software Version: common-sdk 6.2

Description
The GRPC client exposes functionality for getting blocks at a specified block height, along with getting a stream of blocks/finalized blocks from the time of invocation and onwards. It would be helpful to provide users with additional ways to traverse blocks on the chain, more specifically the following methods from the v2 client in the rust SDK:

• get_finalized_blocks_from
• find_instance_creation
• find_first_finalized_block_no_later_than
• find_earliest_finalized

Tasks

• Implementation
• Unit tests
• Examples
• Documentation

Bug Description
I'm not able to use the Concordium Node SDK since Node throws an error when loading the package.

Steps to Reproduce

# Install the packages
npm i @grpc/grpc-js @concordium/node-sdk

# Create a Nodejs script
touch concordium.js

# Edit the script including the imports and save it
nano concordium.js

import { credentials, Metadata } from '@grpc/grpc-js'
import { ConcordiumNodeClient } from '@concordium/node-sdk'

# Run the script
node concordium.js

Expected Result
The script should execute without errors

Actual Result
Nodejs throws an error:

node:internal/modules/cjs/loader:927
  const err = new Error(message);
              ^

Error: Cannot find module '../grpc/concordium_p2p_rpc_grpc_pb'
Require stack:
- /home/stakely/tmp/node_modules/@concordium/node-sdk/lib/client.js
- /home/stakely/tmp/node_modules/@concordium/node-sdk/lib/index.js
    at Function.Module._resolveFilename (node:internal/modules/cjs/loader:927:15)
    at Function.Module._load (node:internal/modules/cjs/loader:772:27)
    at Module.require (node:internal/modules/cjs/loader:999:19)
    at require (node:internal/modules/cjs/helpers:93:18)
    at Object.<anonymous> (/home/stakely/tmp/node_modules/@concordium/node-sdk/lib/client.js:4:38)
    at Module._compile (node:internal/modules/cjs/loader:1095:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1124:10)
    at Module.load (node:internal/modules/cjs/loader:975:32)
    at Function.Module._load (node:internal/modules/cjs/loader:816:12)
    at Module.require (node:internal/modules/cjs/loader:999:19) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [
    '/home/stakely/tmp/node_modules/@concordium/node-sdk/lib/client.js',
    '/home/stakely/tmp/node_modules/@concordium/node-sdk/lib/index.js'
  ]
}

Versions

• Software Version:
  Nodejs 16
  @concordium/node-sdk 2.0.0
  @grpc/grpc-js: 1.6.7

• OS
  Windows and Ubuntu

Task description

For protocol 4, the configure delegation transaction type is added. We should have support for serializing/sending it.

Task Description

Currently, the nodejs-sdk only supports GRPCv1 and we need to also support GRPCv2.

We are starting with these as they are needed by the browser/desktop wallet.

• PR1: getAccountInfo(), getNextAccountSequenceNumber() and getCryptographicParameters()
• PR2: The rest of these. PR1 needs to be merged in, and need type translation.
• PR3: getBlocks() from the GRPCv2 protocol and implement a local "waitForTransactionToFinalize()" function that utilizes it. PR1+PR2 needs to be merged in, and need type translation.
• PR4: getAccountList(), getModuleList(), getAncestors(), getInstanceList(), getInstanceState(), instanceStateLookup()
• PR5: getAnonymityRevokers, getIdentityProviders, getBlocksAtHeight, getBlockInfo, getBakerList
• PR6: getPoolDelegators, getPoolDelegatorsRewardPeriod, getPassiveDelegators, getPassiveDelegatorsRewardPeriod, getBranches
• PR7: getElectionInfo, getAccountNonFinalizedTransactions, getBlockTransactionEvents, getNextUpdateSequenceNumbers
• PR8: shutdown, peerConnect, peerDisconnect, getBannedPeers, banPeer, unbanPeer, dumpStart, dumpStop
• PR9: getPeersInfo, getNodeInfo
• PR10: getBlockSpecialEvents, getBlockPendingUpdates, getBlockFinalizationSummary

Functions merged

49 / 49

• getBlocks
• getFinalizedBlocks
• getAccountInfo
• getAccountList
• getModuleList
• getAncestors
• getModuleSource
• getInstanceList
• getInstanceInfo
• getInstanceState
• instanceStateLookup
• getNextAccountSequenceNumber
• getConsensusInfo
• getBlockItemStatus
• getCryptographicParameters
• getBlockInfo
• getBakerList
• getPoolInfo
• getPassiveDelegationInfo
• getBlocksAtHeight
• getTokenomicsInfo
• invokeInstance
• getPoolDelegators
• getPoolDelegatorsRewardPeriod
• getPassiveDelegators
• getPassiveDelegatorsRewardPeriod
• getBranches
• getElectionInfo
• getIdentityProviders
• getAnonymityRevokers
• getAccountNonFinalizedTransactions
• getBlockTransactionEvents
• getBlockSpecialEvents
• getBlockPendingUpdates
• getNextUpdateSequenceNumbers
• shutdown
• peerConnect
• peerDisconnect
• getBannedPeers
• banPeer
• unbanPeer
• dumpStart
• dumpStop
• getPeersInfo
• getNodeInfo
• sendBlockItem
• getAccountTransactionSignHash
• getBlockChainParameters
• getBlockFinalizationSummary

Todo's:

• Translate and test AR-data (Missing in node until 2023-01-12)
• Get an exhaustive list of Events and RejectReasons (See #119)
• Document account creation for ReadmeV2
• Download raw GRPCv1 calls as test data

Accounts:

• Basic account: 3kBx2h5Y2veb4hZgAJWPrr8RyQESKm5TjzF3ti1QQ4VSYLwK1G
  • CredId: aa730045bcd20bb5c24349db29d949f767e72f7cce459dc163c4b93c780a7d7f65801dda8ff7e4fc06fdf1a1b246276f
• Baker Account (ID: 5): 4EJJ1hVhbVZT2sR9xPzWUwFcJWK3fPX54z94zskTozFVk8Xd4L
• Delegator Account: 3bFo43GiPnkk5MmaSdsRVboaX2DNSKaRkLseQbyB3WPW1osPwh

Description
To allow developers to easily interact with contracts adhering to Concordium contract standards, we will add specialized clients exposing an API matching the API of the contract standard.

Tasks

• Add CIS-2 client
• Add CIS-0 client
• Unit tests
• Documentation
• Runnable examples

Bug Description

util.js's intToString doesn't work (as in it doesn't do anything)
This function is used to parse uint64 types from the node.
The impact of this is that we don't convert number fields into string before letting JS parse it, which means that we have incorrect/lossy parsing of numbers above MAX_SAFE_INTEGER.

When we remove GRPCv1 there is a few things we should look at changing.

• Remove TransactionSummaryType
• Update delegatorId fields in event data to be bigints
• chainParameters.foundationAccount should not be optional

Description
Currently, the process of getting your signing keys is not properly explained.
This task is about delineating the process so that it is easy to get started using the SDK.

As I understand it, there are at least the two following ways:

1. Import and decrypt the mobile wallet export with decryptMobileWalletExport, then find the signing keys inside the (partially typed) record.
2. Import and decrypt the mobile wallet export with decryptMobileWalletExport, then use the IdentityInput to create a new account to which you generate the keys.

Concordium-client can give good error messages when part of the e.g. input parameter is wrongly provided (e.g. Error message: In the JSON input parameter in field token_IDahex stringis expected but gotxyz instead). We should have similar error messages pointing out exactly the field/place that is wrong when using the node SDK functions

• signAndSendTransaction
• serializeUpdateContractParameters
• deserializeReceiveReturnValue

Currently, theses three functions just not serialize/deserialize the value if something is wrong but it is difficult to pinpoint the exact field/area that was wrongly provided. Not exactly sure if deserializeReceiveReturnValue falls under this issue as well but I just mentioned it to investigate.

• Expose the new endpoints stemming from transaction metadata changes.
• Support sending transfers with metadata.

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

Bug Description
When porting parameter serialization from js to rust, the expected type of u64/i64 was changed from bigint to numbers.

• This was not properly documented as the breaking change it is.
• This removes the option to handle numbers >= 2^53 precisely.

Versions

• Software Version
  common-sdk v6.0.0

Task description

The tests added for delegation only works on the Stagenet currently, because Testnet does not have the new version yet.
When we update Testnet, these tests should be changed to work on Testnet instead.

Description
The GRPC client of the JS SDK currently has a method for getting the BlockItemSummary of a transaction, but due to the dynamic nature of this, it is tedious to access common information. The rust SDK adds an implementation layer on top of the BlockItemSummary struct, which trivialises this. We should aim to provide this functionality in the JS SDK as well.

To avoid the need for a new major version due to breaking changes, the helpers should work with the existing BlockItemSummary type instead of mapping this to a structure such as the rust struct.

Tasks

• Implementation
• Unit tests
• Examples
• Documentation

Task description

Currently the tests fail in nodejs SDK on both the old testnet and the new

In the ConcordiumNodeClient class, it would be nice if the following alteration was made, to align the interface with the GRPCv2 client counterpart in the rust SDK:

waitForTransactionFinalization
This method currently returns only the block hash of the block the transaction is included in. It would be useful if the BlockItemSummary for the finalized transaction would be returned in addition to this, instead of having to issue another GRPC request for this.

See v2::client.wait_until_finalized for reference

Bug Description

Currently, using @concordium/web-sdk in an app that does server side rendering (SSR) causes the server doing SSR to crash due to not being able to find a suitable module.

The current workaround woud be to resolve @concordium/web-sdk to @concordium/node-sdk. This is going to be a challenge for a lot of app developers, as it is pretty normal to use frameworks such as nextJS, nuxt, etc. to develop web apps.

Currently, we specify only browser and types field in the published @concordium/web-sdk/package.json.

A solution could be to simply include the node-sdk as part of the web-sdk:

file tree:

/
  package.json
  lib/
    concordium.min.js <-- browser code
    index.js <-- node-js code
    index.d.ts <-- types

package.json:

{
  "main": "lib/index.js"
  "types": "lib/index.d.ts"
  "browser": "lib/concordium.min.js"
  "files": ["lib/*"]
}

We would have to ensure, however, that the nodejs-sdk is identical or a superset of the web-sdk for this to work consistently.

Adding this should not be a breaking change.

grpcV1 will soon be deprecated so we should download the test data and store it locally instead.

Task description
Add support for schema version 2, which matches smart contracts version 1.
Please note that version 1 of the schema should still be supported.

In schema version 2, there is no longer a schema for the state and each function can have optional schemas for a parameter and return value.
Please see https://github.com/Concordium/concordium-contracts-common/blob/020bac62e18eac03af50b36e76b5a4b81eadad15/src/schema.rs#L60 for more details.

It needs to be investigated which of the features are already available. It would be nice to add a tutorial/front-end/smart contract/dapp example focusing on events and handling of it:

It would be nice to have following features:

• When sending a tx to the blockchain, it should be possible to get the events emitted during the tx as part of the information returened by the signAndSendTransaction
• Query a transaction/block to get all events
• (Not in scope!) Filter a large part of the blockchain to return all transactions logged by a specific smart contract and specific event tag (Custom Indexer?)

Addtionally:
Since we use the Rust SDK in various applications internally, it contains a number of useful helper functions and is the most develop SDK we have.
We could go over the API of the Rust SDK and ensure we have something similar in the NodeJS SDK.

Description
The current documentation good for getting an overview of the capabilities of the packages, but we are still lacking the more detailed documentation for understanding types, exceptions and assumptions made by the various functions.
By generating an API reference from the jsdoc comments and types, we could have this information close to the code and make it easier to discover.

I suggest:

• Setup TypeDoc to generate an API reference from the code base.
  Use typedoc-plugin-pages to include the documentation we already have.
• Publish the documentation on GitHub pages for this repo, linking it from the repo.

Task description

As the title states. Some users will need this soon so it would be good to add it.

Task description
It is not clear what the process is for publishing.
How to deal with the changelog, versioning, testing, tagging release on github

Task description
Currently the SDK is not usable outside of nodeJS environments, because the node client uses nodeJS specific libraries, and is everything is exported from the index.

We should restructure the SDK, so that modules reliant on nodeJS is isolated, and the SDK can easily be used in web environments.

Task description
Now that we use the public testnet nodes, we can make the CI run our node tests.

Task description
Work has already been done to support the delegation update (Protocol update 4), #35, but we should ensure that the SDK fully supports the update.

Sub-tasks

• Ensure that types on client calls are updated/versioned
• Add new transaction event types
• Anything else that should be done

We need to be able to parse CIS2 token addresses, this also includes updating the ULEB128 parts of our code.

Task description

The client should be like a CIS2 client for CIS4 contracts.

See https://github.com/Concordium/concordium-rust-sdk/blob/main/src/cis4.rs#L83 for a draft version of the Rust one.

Do note that at this point some details in CIS4 might change since the integration with the wallets is still being done.

Additionally the CIS4 client should be expanded with support for storing credentials, i.e., there should be support for serializing the "additional_data" for the registry contract that can be used for storing credentials.

Sub tasks

• Implement CIS4Contract client
• Add unit tests
• Add examples
• Documentation

Fixing this would be breaking, so it is scheduled for next major release. I created a PR that fixes this: #180

Description
While serialization of return values, events, and errors in smart contracts is not manual (like when developers have to structure JSON parameters to be compatible with the contract schema), it might still provide some form of value to be able to pinpoint why deserialization of these fails. As of now, many of these don’t provide any detail of what fails and where. To help developers identify where the error happens, it would make sense to provide point in the buffer at which deserialization failed, and which type it could not be deserialized to.

Sub-tasks

• docs/gRPC.md
  • Create examples
  • Test examples
  • Pass review
• packages/common/README.md
  • Create examples
  • Test examples
  • Pass review
• Update documentation
  • Setup typedoc
  • Integrate current docs to typedoc
  • Look into inlining examples in docs (See this)
  • Add a typedoc pipeline

Example list
client #164

• banPeer.ts
• dumpStart.ts
• dumpStop.ts
• getAccountInfo.ts
• getAccountList.ts
• getAccountNonFinalizedTransactions.ts
• getAncestors.ts
• getAnonymityRevokers.ts
• getBakerList.ts
• getBannedPeers.ts
• getBlockChainParameters.ts
• getBlockFinalizationSummary.ts
• getBlockInfo.ts
• getBlockItemStatus.ts
• getBlockPendingUpdates.ts
• getBlocksAtHeight.ts
• getBlockSpecialEvents.ts
• getBlocks.ts
• getBlockTransactionEvents.ts
• getBranches.ts
• getConsensusStatus.ts
• getCryptographicParameters.ts
• getElectionInfo.ts
• getFinalizedBlocks.ts
• getIdentityProviders.ts
• getInstanceInfo.ts
• getInstanceState.ts
• getModuleList.ts
• getModuleSource.ts
• getNextAccountSequenceNumber.ts
• getNextUpdateSequenceNumbers.ts
• getNodeInfo.ts
• getPassiveDelegationInfo.ts
• getPassiveDelegatorsRewardPeriod.ts
• getPassiveDelegators.ts
• getPeersInfo.ts
• getPoolDelegatorsRewardPeriod.ts
• getPoolDelegators.ts
• getPoolInfo.ts
• getTokenomicsInfo.ts
• instanceStateLookup.ts
• invokeContract.ts
• peerConnect.ts
• peerDisconnect.ts
• shutdown.ts
• unbanPeer.ts
• waitForTransactionFinalization.ts

common: #193

• aliases.ts
• bakerAdd.ts
• bakerRemove.ts
• delegationAdd.ts
• delegationRemove.ts
• deployModule.ts
• simpleTransfer.ts
• statements.ts
• streamToList.ts

composed examples: #194

• findAccountCreationBlock.ts
• initAndUpdateContract.ts
• listAccountCreation.ts
• listInitialAccounts.ts
• listNumberAccountTransactions.ts

See Epic #152

Bug Description
The client call getModuleSource does not return a versioned module schema, but simply the wasm module as bytes. The schema version information therefore gets lost.

Note that this will be a breaking change.

Description
Links on NPM package is broken

Steps to Reproduce
Visit https://www.npmjs.com/package/@concordium/node-sdk
click on "Note that this package contains and exports the functions from the common-sdk, check the readme of that package for an overview of those."

Expected Result
It should redirect to a readme file

Actual Result
it shows a 404 not found page.

Description

Currently the SDK does not offer a way to deserialize/parse the return value from a contract execution. It could be useful to have such a function.

Task description

For protocol 4, the configure baker transaction type is added. We should have support for serializing/sending it.

We need to test the translation of most TransactionEvents, BlockSpecialEvent and RejectReasons.

Non-existant account

• 39zbDo5ycLdugboskzUqjme8uNnDFfAYdyAYB9csegQJ2BqLoe

Transaction Hashes

Events

• - EventTests-PR1
• - EventTests-PR2
• - EventTests-PR3
• - SpecialEventTests-PR1 (In Review)
• - RejectReasonTests-PR1 (In Review)

36 / 36

• - AccountCreated
  • 67fd6360f39ea6d815133878e64070c578a66012b3eaa757cd1dba8a993079ea
• - AmountAddedByDecryption
  • e59ba7559e2de14e1bd4c05ddbfca808dd5b870cd89eec3942ae29f842906262
• - BakerAdded
  • 04d24b3d44e4ec4681c279424bd276215809a6af64e57fd20cd907a08d998f09
• - BakerKeysUpdated
  • ec886543ea454845ce09dcc064d7bc79f7da5a8c74c8f7cce9783681028a47de
• - BakerRemoved
  • 2aa7c4a54ad403a9f9b48de2469e5f13a64c95f2cf7a8e72c0f9f7ae0718f642
• - BakerSetBakingRewardCommission
  • 04d24b3d44e4ec4681c279424bd276215809a6af64e57fd20cd907a08d998f09
• - BakerSetFinalizationRewardCommission
  • 04d24b3d44e4ec4681c279424bd276215809a6af64e57fd20cd907a08d998f09
• - BakerSetMetadataURL
  • 04d24b3d44e4ec4681c279424bd276215809a6af64e57fd20cd907a08d998f09
• - BakerSetOpenStatus
  • 04d24b3d44e4ec4681c279424bd276215809a6af64e57fd20cd907a08d998f09
• - BakerSetRestakeEarnings
  • 04d24b3d44e4ec4681c279424bd276215809a6af64e57fd20cd907a08d998f09
• - BakerSetTransactionFeeCommission
  • 04d24b3d44e4ec4681c279424bd276215809a6af64e57fd20cd907a08d998f09
• - BakerStakeDecreased
  • 2103b8c6f1e0608790f241b1ca5d19df16f00abe54e5885d72e60985959826ae
• - BakerStakeIncreased
  • 29c4caa0de1d9fc9da9513635e876aa0db0c6ab37fc30e7d2d7883af51659273
• - ContractInitialized
  • 70dbb294060878220505e928d616dde2d90cf5eeee0a92d3fdc1268334ace89e
• - CredentialDeployed
• - CredentialKeysUpdated
  • 387a2f5812b16e4f6543e51007f20b514909de4d7ea39785b83bcd6f1cde9af4
• - CredentialsUpdated
  • 6ce268765af0f59e147a0935980ae3014b9e90b9a43a2d9cf785f19641a9bf64
• - DataRegistered
  • ac4e60f4a014d823e3bf03859abdb2f9d2317b988dedc9c9621e3b7f5dcffb06
• - DelegationAdded
  • 9cf7f3ba97e027f08bc3dc779e6eb4aadaecee0899a532224846196f646921f3
• - DelegationRemoved
  • 65ad6b6a4c9eaccb99a01e2661fcc588a411beb0ed91d39ac692359d5a666631
• - DelegationSetDelegationTarget
  • 9cf7f3ba97e027f08bc3dc779e6eb4aadaecee0899a532224846196f646921f3
• - DelegationSetRestakeEarnings
  • 9cf7f3ba97e027f08bc3dc779e6eb4aadaecee0899a532224846196f646921f3
• - DelegationStakeDecreased
  • f0426a8937438551692bbd777ac61f309fa2adee2dc50c82d6bd6ff151f5ce0a
• - DelegationStakeIncreased
  • 9cf7f3ba97e027f08bc3dc779e6eb4aadaecee0899a532224846196f646921f3
• - EncryptedAmountsRemoved
  • 20314352b6364dc5236e97c97e54cea1ea919538f87ed89b4d4d5101a5a422dd
  • e59ba7559e2de14e1bd4c05ddbfca808dd5b870cd89eec3942ae29f842906262
• - EncryptedSelfAmountAdded
  • 0254312274ccd192288ca49923c6571ae64d7d0ef57923a68d4c1b055e2ca757
• - Interrupted
  • a74a3914143eb596132c74685fac1314f6d5e8bb393e3372e83726f0c4654de2
• - ModuleDeployed
  • c7fd8efa319942d54336ccdfe8460a0591a2a4b3a6bac65fe552198d530105d1
• - NewEncryptedAmount
  • 20314352b6364dc5236e97c97e54cea1ea919538f87ed89b4d4d5101a5a422dd
• - Resumed
  • a74a3914143eb596132c74685fac1314f6d5e8bb393e3372e83726f0c4654de2
• - TransferMemo
  • df96a12cc515bc863ed7021154494c8747e321565ff8b788066f0308c2963ece
• - Transferred
  • a74a3914143eb596132c74685fac1314f6d5e8bb393e3372e83726f0c4654de2
• - TransferredWithSchedule
  • 7696ce3b5e3c5165572984abb250f8ac7c8f42cdc5ca3e1c1f1c387bb878fc94
• - Updated
  • a74a3914143eb596132c74685fac1314f6d5e8bb393e3372e83726f0c4654de2
• - UpdateEnqueued
  • 39122a9c720cae643b999d93dd7bf09bcf50e99bb716767dd35c39690390db54
• - Upgraded
  • 77ffdf2e8e4144a9a39b20ea7211a4aee0a23847778dcc1963c7a85f32b4f27d

Special Events:

8 / 8

• - bakingRewards
  • da7a5401049c8ee0de0b6c66ab4f6167ef770b332df9dd9979ec2c553d1a18dd,
• - blockAccrueReward
  • 4031d210b35a3fb9f13d1ce6e5c621abd9a26a2de54b71fc19bfb55fe17cce6a,
• - blockReward
  • da7a5401049c8ee0de0b6c66ab4f6167ef770b332df9dd9979ec2c553d1a18dd,
• - finalizationRewards
  • da7a5401049c8ee0de0b6c66ab4f6167ef770b332df9dd9979ec2c553d1a18dd,
• - mint
  • 4031d210b35a3fb9f13d1ce6e5c621abd9a26a2de54b71fc19bfb55fe17cce6a,
• - paydayAccountReward
  • 4031d210b35a3fb9f13d1ce6e5c621abd9a26a2de54b71fc19bfb55fe17cce6a
• - paydayFoundationReward
  • 4031d210b35a3fb9f13d1ce6e5c621abd9a26a2de54b71fc19bfb55fe17cce6a,
• - paydayPoolReward
  • 4031d210b35a3fb9f13d1ce6e5c621abd9a26a2de54b71fc19bfb55fe17cce6a,

RejectReasons

31 / 56

• - AlreadyABaker
  • 20324be7fdb1dd2556e5492ac0b73df408bda7f237066cee3c3d71a4804327a4
• - AmountTooLarge
  • 25658e0353cae71a48f25f9ed92682cc096d1463b801676b449cb89c7fa13a1f
• - BakerInCooldown
  • dd47761affcc6446306158cd51b8ab117b81ae5d33413af2b3c4c5f20275fb5f
• - DelegationTargetNotABaker
  • f885db7e2b27953f3f6f10b3c69bf7d9e77bc529768234e4191ecbc6fd4cc47
• - EncryptedAmountSelfTransfer
  • a68ef25ac9b38dfb76884dc797f0b1f924695218107caed3b3e370479d552c3a
• - FinalizationRewardCommissionNotInRange
  • bb58a5dbcb77ec5d94d1039724e347a5a06b60bd098bb404c9967531e58ec870
• - FirstScheduledReleaseExpired
  • 8692bbfd18983543aace1a04596e27ec8f332243b01ed2b6fed28397bf66ff89
• - InsufficientBalanceForBakerStake
  • 1803d84dfaa081e5da1c1dc96bbb65888a65904cba5abcbfc2aad963d2d39097
• - InsufficientBalanceForDelegationStake
  • dce2ce0d5e893e273eb53726e35fb249e3151db2347c624e5d0c5ffce20c4950
• - InvalidAccountReference
  • a37e065c239787a4fca3241580dd37ce354ef97224adf1f34afbf92fdd310b69
• - InvalidContractAddress
  • 30247d68bcca12a0a611bfc412a9a8b28152f501ea957970f1351c528bd58edf
• - InvalidEncryptedAmountTransferProof
  • 6a63a548e2d983cafe65f47a785e1e1dde1ba35f6fe16234602936f4fbecb4dd
• - InvalidInitMethod
  • 2830618959b146313cfc596826e59390f6b8907d33a964ec0663c1d7e975fcfa
• - InvalidModuleReference
  • c6ebed14d387e8d0c3f8120f83d69948b39478d7205e468f4db9b089459ff8c4
• - InvalidReceiveMethod
  • 0b667b6886760c37a176097b390fd1d655e714f2bf19a507b3242d8ee919ed1a
• - InvalidTransferToPublicProof
  • 10f02dba8e75ef25d2eefde19d39624c62600f13a5d91b857283b718017a4471
• - MissingBakerAddParameters
  • 269d3730dd3813dbe5c8104be20bcfe02ee3fbd4a7a3da4fcca1271c38a6e405
• - ModuleHashAlreadyExists
  • ec85ac5f3b7a39ac277aee9e96837c53be3bd3442068a0970ab3badd80fd88e5
• - ModuleNotWF
  • b100e5568b2db7cce2da671ac17d45911447d86340b40a469717c15fd4098dda
• - NonExistentCredentialID
  • be5bd3b147eeababdbf19a0d60b29e2aeddc7eb65e3ab901cbd4f071d5af211c
• - OutOfEnergy
  • 57c632333f9373fbc7ea4ce3306269981560fd87c5a6de23b4a7584604e2c6bc
• - PoolClosed
  • 72c2d0d9634b82ade18616711eb1cb351456b913d1758c4d840759a408b75775
• - RejectedInit
  • b95031d150ae90175c203a63b23f8dafd5a8c57defaf5d287a6c534d4a4ad2d5
• - RejectedReceive
  • 2141282b7a2ec57f3bcce59dc3b0649c80b872ae21a56c2ad300c4002145f988
• - RuntimeFailure
  • 5072f24f681fc5ff9ae09f0b698f8aed20c02bd6990fc59bcb618252ad257355
• - ScheduledSelfTransfer
  • 917ca9e15667a667cad97c7806ea27b78633d6821cc6f1fa29f8aecd238223c5
• - SerializationFailure
  • d3e2e0a0a6674a56f9e057894fcba2244c21242705f9a95ba1052e6ab156eeb1
• - StakeOverMaximumThresholdForPool
  • 5284633bd71b4f8840e9f2e86ced6a4615961248347669d7b5a5a7088422a9f0
• - StakeUnderMinimumThresholdForBaking
  • 4d8a001488e2295911b55822c9fb48fae7deff1bb1e2a36aba54c5f61b8e3159
• - TransactionFeeCommissionNotInRange
  • 102ef7df5a6d1502c6e2b864e182cbb10824d017e88bb90a4cb82e3c054e0bba
• - PoolWouldBecomeOverDelegated
  • c4ae2d1e29ed2dfed7e4a0e08fb419ae6b5cef65cba9ff0c6553ef6377b3e95c

Description
To make it easy to sign transactions using the SDK, it would be helpful to make it possible to create an AccountSigner from

• the format created from exporting from f.x. an account in the browser wallet
• the genesis format

in addition to the currently available creation from private key.

Tasks

• Implementation
• Unit tests
• Documentation
• Examples

can't use parse wallet to get signer and sender

install package and import parsWallet

parse wallet should work

parseWallet not found

Description
To allow developers to easily identify why serialization of JSON formatted contract parameters fails, we need to add trace information to the location of the serialization failure in the object.

Task description

There are some minor changes related to the sync-calls smart contracts features.

• V1 smart contracts add two new events (interrupted and resumed) that should be handled in the SDK.
• Additionally there is a new entrypoint "InvokeContract" that should be added.
• In relation to the previous point, GetInstanceInfo response is now versioned, and V1 does not contain the "model" field.

Task description
Add functions that parses a serialized error from either a receive or init function.

Description

If you import any code that is not just types into a web project, the project cannot compile due to the use of nodeJS packages. We should structure the exported functionality in a way that makes it easy to identify the environment it is intended for, and of course strive to keep as much code agnostic of runtime environment.

An example could be:

• Environment agnostic: @concordium/node-sdk
• NodeJS only: @concordium/node-sdk/nodejs
• Browser only: @concordium/node-sdk/browser

Bug Description

Try .. catch block is missing in deserializeTypeValue function which causes the errors not to be thrown correctly.
https://github.com/Concordium/concordium-node-sdk-js/blob/main/packages/common/src/deserialization.ts#L321

See the Try .. catch blocks in the above functions on how errors are thrown.

Steps to Reproduce

Running the [front-end] (Concordium/concordium-misc-tools#55) and choosing the wrong_schema option at one of the two dropDowns at the front end then pressing the button in that test unit should cause an error. When comparing these two errors:

When comparing the errors returned by the functions deserializeReceiveReturnValue() and deserializeTypeValue():

The error from deserializeTypeValue() can not be cast correctly. (err as string) is used in the below line to overcome this issue:
https://github.com/Concordium/concordium-misc-tools/blob/171c7a82549db58f1db5d53b21ec1a7805754315/wallet-connect-test-bench/src/Transactions.tsx#L170

The error from deserializeReceiveReturnValue() can be cast correctly. (err as Error).message is used in the below line:
https://github.com/Concordium/concordium-misc-tools/blob/171c7a82549db58f1db5d53b21ec1a7805754315/wallet-connect-test-bench/src/Transactions.tsx#L158 (edited)