Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add block-based waiting for /poll, /listen, /spv endpoints #33

Open
LindaOrtega opened this issue Jul 8, 2022 · 3 comments
Open

Add block-based waiting for /poll, /listen, /spv endpoints #33

LindaOrtega opened this issue Jul 8, 2022 · 3 comments
Labels
discussion Needs (architectual) discussion to make a decision no-issue-activity

Comments

@LindaOrtega
Copy link
Contributor

I'm creating this issue as a way to discuss the following problem:

As I'm working with the integration tests and devnet, I am having to wait a bit for blocks to come in since devnet is not as fast in producing "blocks" as pact-server.

In the code I'm setting a couple of sleep timers for some arbitrary time. This is a point of indeterminism.
I've seen this when working with /poll, /listen, and /spv endpoints.

A helper function that can be given one of the api fetch functions and that utilizes both a time-based and a block-based exponential backoff would be useful in this situation.

@LindaOrtega
Copy link
Contributor Author

LindaOrtega commented Jul 8, 2022

If the /spv endpoint is queried too soon, you'll see the following error:

SPV target not reachable: target chain not reachable. Chainweb instance is too young

It seems that you have to wait about 3 cut heights (sometimes a little more) between when you submit the cross-chain transaction and when you query the spv endpoint.

Update:
In worst case it is 6 block heights (module off-by one errors).
Assume that the target chain was lagging behind when the the burn happens on the source. In worst case it would take 3 blocks for the target chain to get to the block height at which the burn occurred and another 3 blocks until the proof becomes available.

@LindaOrtega LindaOrtega added the discussion Needs (architectual) discussion to make a decision label Jul 14, 2022
@LindaOrtega
Copy link
Contributor Author

Wrapping /listen and /spv in an exponential-backoff function worked for fixing the inconsistency with the integration-tests on devnet. But we might still want to explore a more tailored approach for this issue.

From conversation with @mightybyte:

Potential place of inspiration for how often to query: https://en.wikipedia.org/wiki/Cycle_per_second
Also, across testnet and mainnet (and potentially devnet) and for a given chain, a user can expect an average of 1 block every 30 seconds.
Consequently, users should expect the overall cut height to increase by 20 (the total number of chains currently in the network) every 30 seconds.

@github-actions
Copy link
Contributor

This issue is stale because it is open for 60 days with no activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Needs (architectual) discussion to make a decision no-issue-activity
Projects
None yet
Development

No branches or pull requests

1 participant