Skip to content
This repository has been archived by the owner on Aug 2, 2022. It is now read-only.

Allow struct serialization from array input #806

Open
wants to merge 2 commits into
base: develop
Choose a base branch
from

Conversation

conr2d
Copy link
Contributor

@conr2d conr2d commented Oct 16, 2020

Change Description

eosio::chain::abi_serializer in libchain allows serialization of struct from array, but eosjs only serializes object to struct.

When sending a transaction with transaction_extensions, the abi of transaction in eosjs defines transaction_extensions as extension[], and extension is a struct with two fields, type (uint16) and data (bytes). However, during calling transact(), it calls /v1/chain/get_required_keys RPC, but in libchain, transaction_extensions is defined by std::vector<std::pair<uint16_t,vector<char>>>, so get_required_keys will be aborted, because libchain will fail to convert the parameters in json to eosio::chain::transaction.

At this time, there is no way to send a transaction with transaction extensions by transact() of eosjs-api. This PR will provide a way to serialize structs from array in the same manner as eosio::chain::abi_serializer and user experience of cleos. Moreover, user can send a transaction with transaction_extensions by setting them in array like:

const tx = {
  actions: [{
  ...
  }],
  transaction_extensions: [[1, [1]], [2, [1, 2, 3, 4]]]
};

API Changes

  • API Changes

User will be able to pass action parameters by array instead of object.

Documentation Additions

  • Documentation Additions

User can pass an array to transact() of eosjs-api.

@tbfleming
Copy link
Contributor

transaction_extensions must always be empty

@conr2d
Copy link
Contributor Author

conr2d commented Oct 16, 2020

@tbfleming Interesting. Can you explain what the intended usage of transaction_extensions is?

I can understand there can be a planned way to use transaction_extensions in EOS mainnet in the future, but what about EOSIO-variants, called sister chains? They might utilize transaction_extensions fields not to modify libchain too much, but implement their own special features by parsing transaction_extensions in wasm-side.

Even if the emptiness of transaction_extensions is mandatory, this PR still has meaning, because this adopts the exisitng way to serialize struct like eosio::chain::abi_serializer does.

@tbfleming
Copy link
Contributor

The intended use is to allow future hard forks to upgrade the transaction format. For now, the JSON representation requires either the field be absent or it be an empty array. The binary form requires a single 0 byte (this is how empty arrays are encoded).

If forks of eosio modify the transaction format, then we can't guarantee any compatibility with versions we maintain. Chances are high they'd conflict.

We were once considering supporting array syntax for objects in eosjs. I thought we had implemented that, but I could be remembering wrong.

@conr2d
Copy link
Contributor Author

conr2d commented Oct 17, 2020

@tbfleming Thank you. :)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants