Closed vitvly closed 6 years ago
Moved web3j-related code and tracker-related code to separate namespaces.
QA notes:
As expired deployments/submissions/watches are re-executed now, it is necessary to check whether they actually do:)
Queries below will simulate a situation where a tx hash for deployment/execution haven't been mined in 15 minutes, therefore making it a candidate for re-execution.
update issues set transaction_hash='<some_nonexisting_hash>', contract_address=null, updated=updated - interval '15 minutes' where issue_id=<issue_id>;
update issues set execute_hash='<some_nonexisting_hash>', confirm_hash=null, updated=updated - interval '15 minutes' where issue_id=<issue_id>;
Mainnet
)Steps: Requirements: GH account is whitelisted, signed app, test application is added to repo;
all transactions are mined successfully
3 of 8 transactions are canceled because of timeout (currently 5 min)
Steps: Requirements: GH account is whitelisted, signed app, test application is added to repo;
1 comment (unsuccessful comment from bot will be replaced with successfull)
2 comments are persisted
I suggest to replace it with 3- to timeout time(IMO 10 min)
bounty
label (6-10 items simultaniously; contract is deployed one-by-one);Tested on Ropsten and Mainnet.
Comment 3. 'Deploying contract' - usually takes 1-2 min - is too optimistic depends on network speed and should be checked on prod and discussed separately, probably will move to the separate issue.
@martinklepsch please merge if it is OK after review; QA is passed.
This PR does the following:
eth/track-tx!
andeth/untrack-tx!
Some additional refactors have been made:
eth/execute
dispatched on the value ofoffline-signing?
update-[name]-hash
with a generic update fntx-info
maps frometh/execute
fn. These are afterwards passed toeth/[un]track-tx!
fns for DB/in-memory storageAfter QA:
Small issues to fix: