Discrepancy between testrpc and Parity

[roderik]

My Solidity contract has the following data structures (among others)

  struct Purchase {
      uint endTime; 
      string pubKey;
  }

  struct InternalUserPurchase {
    mapping(string => Purchase) purchases;
    string[] keys;
  }

  mapping(address => InternalUserPurchase) internalPurchases;

This function returns the correct amount (6 in this case)

  function getPurchasesCount() public constant returns (uint) {
    return internalPurchases[msg.sender].keys.length;
  }

Now I try to get the key out of the "keys": (this key goes on to get stuff from the purchases mapping, but I've taken this out to try and debug this:

  function getPurchaseByIndex(uint index) public constant returns (string streamKey) {
    InternalUserPurchase internalPurchase = internalPurchases[msg.sender];
    string[] thekeys = internalPurchase.keys;
    return thekeys[index];
  }

In testrpc, this returns what I expect. Using parity (latest 1.5 version out of homebrew on osx with a proof of authority setup), web3 (0.18.2) errors out with "new BigNumber() not a base 16 number: ".

The code appears to be correct, apart from the fact that it is a mapping and array inside another mapping. Top level array/mappings in the same contract work like expected, also on Parity.

[roderik]

I ran the same code as a test on Geth, and there it works perfectly

[gavofyork]

the code responsible for this is in web3.js - the bug is almost certainly there. is it possible you're using different versions of web3.js between geth and parity? if you're certain the issue lies with parity, please provide an RPC trace (--logging rpc=trace); when you make the same function call on the object, you'll see an eth_call trace appear in parity's logs. attempt to run the according eth_call RPC within your geth environment. assuming you get different results, then report the call along with the two differing geth/parity results here. if they're the same result then something is going wrong in web3.js.

[tomusdrw]

Seems that the issue was caused by missing from, currently Parity will use default account if from is not provided #4332.
Please re-open in case I've misinterpreted that it's resolved.