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

Consider backing off if RequestBroadcast errors #632

Open
masih opened this issue Sep 5, 2024 · 1 comment
Open

Consider backing off if RequestBroadcast errors #632

masih opened this issue Sep 5, 2024 · 1 comment
Assignees
Labels
enhancement New feature or request

Comments

@masih
Copy link
Member

masih commented Sep 5, 2024

The GPBFT implementation here silently logs errors that occur as a result of requesting broadcast.

In practice, if such situations occur it may be better to backoff from sending consecutive requests, e.g. that may be caused by pubsub congestion.

Using a circuit breaker pattern at host implementation in f3 package might just do the trick without the need for larger refactor across the core gpbft package/protocol changes.

Originally posted by @Stebalien in #627 (comment)

@rjan90
Copy link
Contributor

rjan90 commented Sep 9, 2024

2024-09-09: Discussed in the daily sync that it is lower on the priority list and therefore I will not assign Milestone 2: Hardening and Mainnet Deployment Readiness to this ticket. Might be revisited during the colo

masih added a commit that referenced this issue Oct 9, 2024
GPBFT presciently ignores broadcast and rebroadcast requests as it is
beyond its boundaries of responsibility to do something about. In
practice such failures may be a sign that pubsub is overwhelmed with
messages. Therefore, ideally the system should avoid aggravating the
situation by requesting further broadcasts. This is specially important
in re-broadcast requests because it often involves batch message
publication.

The changes here wrap the pubsub publication calls with a circuit
breaker that will open on consecutive errors (set to `5`), and will not
attempt to actually publish messages until a reset timeout (set to `3s`)
has passed.

Fixes #632
masih added a commit that referenced this issue Oct 9, 2024
GPBFT silently ignores broadcast and rebroadcast requests as it is
beyond its boundaries of responsibility to do something about. In
practice such failures may be a sign that pubsub is overwhelmed with
messages. Therefore, ideally the system should avoid aggravating the
situation by requesting further broadcasts. This is specially important
in re-broadcast requests because it often involves batch message
publication.

The changes here wrap the pubsub publication calls with a circuit
breaker that will open on consecutive errors (set to `5`), and will not
attempt to actually publish messages until a reset timeout (set to `3s`)
has passed.

Fixes #632
@masih masih self-assigned this Oct 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: In review
Development

Successfully merging a pull request may close this issue.

2 participants