is getSubState supposed to work ?

[SvenMeyer]

deployed_contract.getState()gives me a full list of contract states :

{ _balance: '0',
  price: '0',
  ipfsInventory: [ { key: 'Qm001', val: [Object] } ],
  registered_items:
   [ { key: '0x7bb3b0e8a59f3f61d9bff038f4aeb42cae2ecce8',
       val: [Array] } ] }

but all calls to getSubStatereturn undefined :

const state_inv = await contract.getSubState('ipfsInventory');
const state_reg = await contract.getSubState('registered_items', ['0x'+ACCOUNT_0_ADDRESS]);

console.log(`\nGetting a particular entry in a map`);
const state3 = await proof_ipfs.getSubState('ipfsInventory', ['Qm001']);

[SvenMeyer]

getStateis working on kaya but getSubState not and always just returns undefined.
Even easier to replicate example:

console.log(await deployed_contract.getState());
state = await deployed_contract.getSubState('_balance');
console.log({state});

dev testnet :

{
    "_balance": "0",
}
{ state: { _balance: '0' } }`

kaya on localhost:

{
    "_balance": "0",
}
{ state: undefined }

[edison0xyz]

GetSubState is not working. Help and PR appreciated!

[SvenMeyer]

As I noticed that even getState returns the data in a different format than Testnet.
I am wondering: (why) is kaya not using the same code base as Testnet and Mainnet?
Eventually the goal is to have a local Development net which behaves identical to the real networks. Of course it will be very difficult and time consuming to try to replicate the behaviour of the real networks ...

[edison0xyz]

You're right, we are definitely thinking of reusing the codebase. Zilliqa's team has been working on this feature called "isolated server", which aims to promote reusability of the code for dApp developers.

The feature is pending approval to be merged to Zilliqa's codebase: Zilliqa/Zilliqa#1879

The setup instruction is attached here: https://github.com/Zilliqa/Zilliqa/blob/feature/kaya_binary/ISOLATED_SERVER_setup.md

You can give it a try - however, there are a few differences from kaya

1. zilliqa's codebase can be rather verbose and may contain a lot more log information than you need.
2. the memory consumption of this "isolated server" will be much larger than kaya-rpc
3. certain users might find it hard to set up the isolated server

In the long run, we hope to actively maintain kaya-RPC as we believe it's useful for dApp developers. However, recently I've been caught up with many other priorities and I'm struggling to find time to maintain this kaya-RPC.

We will definitely appreciate if community members can make a pull request to make this kaya-rpc better