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

Configurable timeout for HeaderReader polling #2507

Merged
merged 2 commits into from
Jul 22, 2024

Conversation

Tristan-Wilson
Copy link
Member

@Tristan-Wilson Tristan-Wilson commented Jul 19, 2024

Previously if the backend stopped responding the
client.HeaderByNumber call inside the timed main loop would never return, meaning that if the HeaderReader was only operating in polling mode, calls to LastHeader would always return the last successfully fetched header until OldHeaderTimeout, and if that was set to a high duration then it would effectively always return the last successfully fetched header and never an error. This would lead to the chain appear to be stuck and not advancing to clients of HeaderReader.LastHeader.

This change adds a configurable timeout on this call, defaulting to 5s. Other places in HeaderReader that use HeaderByNumber use the passed-in context which the client can control, so no extra timeout was added for these.

NIT-2688

ty @a-thomas-22 for the detailed issue report that made it possible to find this.

Previously if the backend stopped responding the
client.HeaderByNumber call inside the timed main loop would never
return, meaning that if the HeaderReader was only operating in polling
mode, calls to LastHeader would always return the last successfully
fetched header until OldHeaderTimeout, and if that was set to a high
duration then it would effectively always return the last successfully
fetched header and never an error. This would lead to the chain appear
to be stuck and not advancing to clients of HeaderReader.LastHeader.

This change adds a configurable timeout on this call, defaulting to 5s.
Other places in HeaderReader that use LastHeader use the passed-in
context which the client can control, so no extra timeout was added for
these.
@cla-bot cla-bot bot added the s Automatically added by the CLA bot if the creator of a PR is registered as having signed the CLA. label Jul 19, 2024
Copy link
Contributor

@diegoximenes diegoximenes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approving, but race test is failing, not sure if it is a flaky test

Copy link
Contributor

@tsahee tsahee left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@Tristan-Wilson Tristan-Wilson merged commit e645114 into master Jul 22, 2024
13 checks passed
@Tristan-Wilson Tristan-Wilson deleted the timeout-for-headerreader-headerbynumber-calls branch July 22, 2024 16:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
design-approved s Automatically added by the CLA bot if the creator of a PR is registered as having signed the CLA.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants