2

Hey guys I'm hitting an error while trying to query my RAM tables - the table definition has vectors of custom structs in it, and for some reason throws an error regardless of the datatype in the structure, and whether the vector even includes any entries. The error is:

 Unable to unpack built-in type 'name' while processing 'tableobj.vectorobj[1].description'
read datastream of length 45 over by -3
error unpacking uint64_t
Error unpacking field value
error unpacking eosio::chain::name

(description was previously a string, I just updated to name to see if data type was the issue, but received same error, just unable to unpack built-in type string instead of name)

The table structure is:

struct [[eosio::table]] tableobj{
        name creator;
        name platform;
        std::vector<vectorstruct> vectorobj;
        auto primary_key() const {return creator.value;}
    };

and the structure:

struct vectorstruct{
        name username;
        name description;
        EOSLIB_SERIALIZE( vectorstruct, (username)(description) )
    };

The error always throws on the vector index that's empty (non-existent) - if I put one entry into the vector, then it fails on [1], if it's empty, it fails on [0] etc

Can build/push the object into the table without issue, issue only occurs on attempting to query it using cleos get table or zeus get-table-row (tested in both vRAM through a DSP and normal RAM in EOSIO)

Thank you in advance for any help on this, been banging my head against the wall on it

Improve this question

2 Answers 2

Reset to default
2

I resolved the issue by moving the vectors into separate objects, then referencing those objects in the table definition:

struct teststruct{
  name compname;
  std:vector<anotherstruct> structs;
  EOSLIB_SERIALIZE(teststruct, (compname)(structs))
}

struct [[eosio::table]] testtable{
  name owner;
  teststruct tststr;
  auto primary_key() const {return owner.value;}
}

Then re-deploying on a new contract/account entirely, and now it's working! Hopefully helps someone else having a similar issue.

EDIT The aspect that fixed the issue was actually that I had deployed it to a new contract - the table definitions, once changed, need to be re-named for them to build/read correctly. Deleting all rows from the table does not "reset" them, I've needed to rename the table each time I've made an update to the structure.

Improve this answer
2

This error is usually caused by having a table that contains data in a specific format and then updating the ABI after the fact to change the data types or structures.

The ABI file now thinks that all the data in the table is in the new format, but it isn't, and therefore the amount of bytes it tries to read for each of the field entries is no longer correct.

The reason deploying it on a new contract worked is because the new contract had an empty table, and therefore the ABI file had no issues.

See these questions for more information on table migrations:

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.