Closed KipCrossing closed 4 years ago
No. The API will ALWAYS return the MINIMUM information, and will only return things which were 'chosen' by the handler (like txid)
const blkNo = (await w3.eth.getTransactionReceipt(txid_1)).height
so moving the work doesn't do anything but hide problems (note: don't know why you'd care about the block height anyway; reorgs are still possible for example, so the answer from API are not authoritative)Addendum: when moving quickly like we are, the only real "hard no" type thing to implementation is unsafe architecture (which would also have highest techdebt). Like relying on the API returning things could mean lots of refactoring later.
The way the system should work from a redux-esq PoV: (at least this is how I've done it)
{_networkParams: NetworkParams}
{specHashes: Set<bytes32>}
{ballotSpecs: Dictionary<bytes32, BallotSpec>}
So most/all of the functions to do with voting-level ops should basically take the networkParams (note: can be omitted with some designs), a specHash as their second param, and then operation-specific stuff
Looks like hexlify
doesn't take str
:
Error pushing to chain: a bytes-like object is required, not 'str'
[' File "/home/kipling/Programs/voting-app-api/update_ballotspecs_db.py", line 75, in update_ballotspecs\n "specHash": render_spec_hash(id),\n', ' File "/home/kipling/Programs/voting-app-api/update_ballotspecs_db.py", line 69, in render_spec_hash\n return "0x" + ("00" * (32 - len(_s)) + hexlify(_s).decode(\'ascii\'))\n']
CONTINUING
@XertroV When hilling "https://api.blockchain.suzuka.flux.party/members/api" with
'method': 'ballot_publish'
Could I get more back than just the
billCreationTxid
? It would be good to also get the:Int