Retry time fixes #4867
Merged
Retry time fixes #4867
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Update the bigledger peers state in case of an exception. Previously the publicRoot state was updated instead. This ment that in case of an error the node would never attempt to increase the number of big ledger peers again.
The bootstrap peers and public root peers should be different. Therefor the failure of one kind shouldn't automatically carry over to the other kind.
Lower the maximum retry timer from above 1h to 4 minutes. Normally public roots have a ttl of 5s when taken from the ledger. But for bootstrap peers the ttl from DNS will be returned. Since this can be hours or days we cap it to 60s and depend on backoff counter to increase it further if needed.
When calculating publicRoot lookup results having only configured peers with IP addreses is not a DNS failure. Instead of a 3h TTL use 60s for IP addresses only (will be increased by backoff logic).
karknu
force-pushed
the
karknu/retry_fixes
branch
from
d32f6a1 to
0ef9e22
Compare
|
These all look sensible to me :) |
bolt12
approved these changes
Apr 30, 2024
Comment on lines
+109
to
+111
| inProgressBigLedgerPeersReq = False, | ||
| bigLedgerPeerBackoffs = bigLedgerPeerBackoffs', | ||
| bigLedgerPeerRetryTime = bigLedgerPeerRetryTime' |
If we are above the credits instead of failing instantly take a look if any of the events provide us with more credits. This makes the test suite more robust incase one kind of events happens close to another kind of events. For example a burst of peersharing activity just before the node starts to look for new public roots.
bolt12
approved these changes
May 2, 2024
coot
reviewed
May 2, 2024
7 tasks
|
One of the tests failed on Hydra |
This breakage seems to have been introduced in a38e5a1 , that is it exist in master. |
|
I have looked into it and it seems it happens on an edge case when there's a trusted local root peer being in progress promote to cold and then the targets change to be all 0 (due to the quickcheck arbitrary script). This will clamp the local roots to the |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Description
Fix problems related to big ledger and public root peers retry time.
Checklist
Quality
Maintenance
ouroboros-networkproject.