The same way Tx wait for their parent, this PR add the wait for the deploy Tx associated to the Tx program id if not present.
Only Run tx are tested for program id because proof and verify Tx depend on the Run. If the Run wait for the program id proof and verify Tx will wait for the run.
I synchronize the wait verification and the Tx save because some time Wait Tx verification can return several Txs and if it contains a Run Tx for example, the dependent proof that arrive after can be saved before because the batch of Tx take more time to save than one Tx verification and save.
I add the case in my test.
I declare a specific storage trait for the verification.
With the wait_if_not_cached function I try to share the same logic between the program dep and the parent dep verification but not sure, it adds because of the complexity to make it with async future.
The same way Tx wait for their parent, this PR add the wait for the deploy Tx associated to the Tx program id if not present. Only Run tx are tested for program id because proof and verify Tx depend on the Run. If the Run wait for the program id proof and verify Tx will wait for the run.
I synchronize the wait verification and the Tx save because some time Wait Tx verification can return several Txs and if it contains a Run Tx for example, the dependent proof that arrive after can be saved before because the batch of Tx take more time to save than one Tx verification and save. I add the case in my test.
I declare a specific storage trait for the verification.
With the
wait_if_not_cachedfunction I try to share the same logic between the program dep and the parent dep verification but not sure, it adds because of the complexity to make it with async future.I test it with 3 nodes connected.