Treat block numbers as strings, not BigNums.

[gavofyork]

No description provided.

[ngotchac]

I think that this should fix the bug : https://github.com/paritytech/parity/pull/5405/files#diff-82dc1975e34f0323a02d1c76fe49530cR69 We don't really use implicit casting to Numbers anywhere else in the code, might want to keep it that way

[gavofyork]

that won't fix transactionReceipt.blockNumber being a string though, will it?

[ngotchac]

That's right, but it shouldn't be a string AFAICT. Is it?

[gavofyork]

it failed in the same way - might have been a bignum.

[jacogr]

We don't actually format blockHeight as BigNumber in the output formatter, so it just passes what it receives from the RPC call. For consistency, it should be done since all numbers are passed as BigNumbers.

(blockNumber is a BigNumer, so it should not have had the same issue)

[ngotchac]

But blockHeight is not returned by the RPC call, it's computed on the JS side.

[gavofyork]

bignumber still breaks. it is expecting a straight JS number. all of those type coersions are needed for it not to break for me.

[jacogr]

Well, the approach works. However, now that we display via +blockHeight/blockNumber we are not consistent with what we have in the UI, i.e. all blockNumbers are

1. treated as BigNumbers (calculated and passed around)
2. formatted using toFixed(), i.e. will display 3,456,789 instead of 3456789 as it does in this case

The preferred approach would have been to calculate the blockHeight as a BigNumber and use that, instead of making it a string

Making as mustnt-grumble since it solves the immediate issue, however should be fixed at the route to be consistent in a follow-up.