Update detection of successful transaction for byzantium #222
Conversation
The field is returned as int and cannot be unmarshalled to string. The field can be either 0 (fail) or 1 (success).
|
https://github.com/ethereum/wiki/wiki/JSON-RPC#hex-value-encoding https://github.com/ethereum/wiki/wiki/JSON-RPC#eth_gettransactionreceipt
Report it to parity, I am having hard time messing with their own bugs because last time I tested this rpc call there was hex. Now it's an integer. Tomorrow it will be a hex again and we must patch it again. Is it hex in stable 1.7.x? |
|
Actually it was integer in both. I initially used stable but updated to 1.8.2 hoping it was that other bug, but it wasn't; they both seem to be returning integers... sorry about that. I don't know how to fix parity, so I just made this change on my pool (=your pool) to make it work right now as it was not unlocking blocks - I was not aware that they have to conform to standards. I agree that this is a mess and that it should be fixed on their side instead, so do with this PR as you wish :) |
|
Oh, so it is. openethereum/parity-ethereum#6920 openethereum/parity-ethereum#6887 explains it a bit more... |
|
Yes, it was int in parity shit always, i just confused it. I used private network where status is always |
|
Since this is not actually an issue in your code and since it will eventually be resolved by openethereum/parity-ethereum#6926 whenever that's merged, I'll be closing this PR. Thanks for the pool software! :) |
The field is returned as int and cannot be unmarshalled to string. The field can be either 0 (fail) or 1 (success).
More details: https://ethereum.stackexchange.com/questions/28077/how-do-i-detect-a-failed-transaction-after-the-byzantium-fork-as-the-revert-opco