Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
fix: internal listeners infinite retry loop #284
base: main
Are you sure you want to change the base?
fix: internal listeners infinite retry loop #284
Changes from 7 commits
db4725b
4fbcd76
ec76fae
eb5514d
a6c6e3c
b724fc9
3f39061
16f88ff
e77ed5d
e89e058
cbcb2c6
a568006
416f51a
c9e2df2
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, this test does not seem to test that requests are not retried. I believe what it tests is that the promise that
getLatestBlock
returns eventually resolves or is rejected. Should we be more clear here? Something like:Or do we have a way to test that requests are not retried?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, perhaps the original test name is fine. I guess the test would fail if the polling loop continued because we are using
numAutomaticCalls: 1
. Maybe the new test name I am suggesting is appropriate for the case you mentioned above, or something.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we want to explain why excluding internal listeners are necessary? Perhaps something like:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By the way, I was playing around with this PR and it seems that if you revert the changes to
destroy
and_getBlockTrackerEventCount
, then your test still works. It seems that listening toerror
solved at least one bug. But perhaps there is another test we need to write to verify the endless loop bug? I can take another look tomorrow to see what that would be.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I'm thinking that this would not cover the scenario where the block tracker is destroyed before fetching the first block and without throwing errors.
We can probably listen to
_ended
insteadThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like
_ended
could present other issues, because of the weird order of events received:_start
is emitted_ended
event listener is executedlatest
event listener is executedThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I understand correctly, because
getLatestBlock
now relies onlatest
orerror
to fire in order to resolve the promise it creates, if that never happens because thefetch
call never happens, thengetLatestBlock
will just hang, even ifdestroy
is called?I think listening to
_ended
could make sense. Perhaps we add a check inonLatestBlockAvailable
that only resolves the promise if the block runner is still running?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am slow today :/ It seems that Mark's solution in #286 may solve that case, because it grants
destroy
access to the promise thatgetLatestBlock
creates, and we can just force-reject it if it hasn't resolved yet.