Re-merge go-algorand 3.1.3-beta #3230
Merged
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
…cleci nightly testing. (#3016) For CircleCI testing, increase machine size from medium to large and set parallelism to 4.
Our travisci keeps breaking for different reasons so we decided to move our deploy to circleci.
go-algorand 3.1.0-beta
Noticed our environment passing variable is not working as intended, implemented a different way of passing it.
Fixing CircleCI deploy for Betanet and Stablenet (#3077)
## Summary When a 2.1 (i.e. no txsync) client connects to a 3.0 relay (i.e. txsync), the relay needs to request the client to keep sending it a TX messages - otherwise, these transactions would not get propagated. The 2.1 and 3.0 above are network protocol versions, not a algod release version. ## Test Plan e2e test added.
3.1.1 hotfix
…tion messages (#3102) Summary This PR adds the missing bridge between the txnsync and the classic transaction relaying: when a transaction message arrive and being added to the transaction pool, we need to attempt to relay these messages right away using the classic transaction messages. That would allow relays to be compatible with both 2.1 and 3.0 nodes. Test Plan e2e test was added.
go-algorand v3.1.2-beta
## Summary During fast catchup, we restart the transaction sync service very quickly. This can cause a network message being sent, and the response would be returned to the "restarted" txnsync. Since we don't want to disconnect the network connection itself ( which could have some messages enqueued ), the transaction sync would need to store the "returned" channel before sending the message. That would avoid the data race ( and safely ignore the incoming message ). ## Test Plan Use existing testing, and confirm against that.
## Summary This PR adds the node ( both client and server ), the ability to measure the time it takes to establish an outgoing connection ( excluding the TCP connection time ). This duration is captured as the initial latency, which would need to get updated via a pingpong style logic. ## Test Plan - [x] Extend existing unit tests - [x] mainnet-model testing is needed as well to confirm correctness
## Summary
I noticed log messages like this:
```
{"file":"txHandler.go","function":"github.com/algorand/go-algorand/data.(*solicitedAsyncTxHandler).loop","level":"info","line":541,"msg":"solicitedAsyncTxHandler was unable to relay transaction message : %!v(MISSING)","time":"2021-10-20T23:18:40.220089Z"}
{"file":"txHandler.go","function":"github.com/algorand/go-algorand/data.(*solicitedAsyncTxHandler).loop","level":"info","line":541,"msg":"solicitedAsyncTxHandler was unable to relay transaction message : %!v(MISSING)","time":"2021-10-20T23:18:40.220226Z"}
{"file":"txHandler.go","function":"github.com/algorand/go-algorand/data.(*solicitedAsyncTxHandler).loop","level":"info","line":541,"msg":"solicitedAsyncTxHandler was unable to relay transaction message : %!v(MISSING)","time":"2021-10-20T23:18:40.220300Z"}
{"file":"txHandler.go","function":"github.com/algorand/go-algorand/data.(*solicitedAsyncTxHandler).loop","level":"info","line":541,"msg":"solicitedAsyncTxHandler was unable to relay transaction message : %!v(MISSING)","time":"2021-10-20T23:18:40.228731Z"}
{"file":"txHandler.go","function":"github.com/algorand/go-algorand/data.(*solicitedAsyncTxHandler).loop","level":"info","line":541,"msg":"solicitedAsyncTxHandler was unable to relay transaction message : %!v(MISSING)","time":"2021-10-20T23:18:40.228828Z"}
{"file":"txHandler.go","function":"github.com/algorand/go-algorand/data.(*solicitedAsyncTxHandler).loop","level":"info","line":541,"msg":"solicitedAsyncTxHandler was unable to relay transaction message : %!v(MISSING)","time":"2021-10-20T23:18:40.228893Z"}
{"file":"txHandler.go","function":"github.com/algorand/go-algorand/data.(*solicitedAsyncTxHandler).loop","level":"info","line":541,"msg":"solicitedAsyncTxHandler was unable to relay transaction message : %!v(MISSING)","time":"2021-10-20T23:18:40.228946Z"}
{"file":"txHandler.go","function":"github.com/algorand/go-algorand/data.(*solicitedAsyncTxHandler).loop","level":"info","line":541,"msg":"solicitedAsyncTxHandler was unable to relay transaction message : %!v(MISSING)","time":"2021-10-20T23:18:40.229012Z"}
{"file":"txHandler.go","function":"github.com/algorand/go-algorand/data.(*solicitedAsyncTxHandler).loop","level":"info","line":541,"msg":"solicitedAsyncTxHandler was unable to relay transaction message : %!v(MISSING)","time":"2021-10-20T23:18:40.229080Z"}
```
## Test Plan
No test changes.
## Summary The previous web socket version was not flushing the write buffer when writing a Close control message. As a result, we ended up disconnection the connection on one side correctly, while having it in a zombie state on the other side. ## Test Plan Use existing tests. The `TestSlowPeerDisconnection` was already observing the issue being resolved.
## Summary Improve the bandwidth estimation within the transaction sync by having the estimation account for latency, transaction compression time, and time spent waiting in the incoming queue. ## Test Plan Wrote unit tests for correctness, ran network on mainnet model and observed measured bandwidths. Before the bandwidth would converge to the minimum over time as well have erratic inaccuracies. Now the numbers look much more in range, at most a factor of 2 off.
## Summary Running betanet, we've seen errors such as ``` unable to enqueue incoming message into peer incoming message backlog. disconnecting from peer. ``` as well as multiple ``` Peer 162.202.32.72:56543 disconnected: SlowConnection ``` The goal of this PR is to remove from the pending incoming message queue entries that are associated with network peers that have been disconnected ( by the network package ), or have been scheduled for disconnection ( by the transaction synch package ). Removing these would increase the "available" space in the incoming message queue and would prevent redundant disconnections. ## Test Plan - [x] unit tests updated. - [x] ran s1 network with and without load, successfully.
## Summary The catchup was occasionally reporting ``` (1): fetchAndWrite(13932148): ledger write failed: block evaluation for round 13932148 requires sequential evaluation while the latest round is 13932148 ``` This issue indicates that the catchup was attempting to validate a block which is not the latest+1, but rather newer. In this case, we can safely ignore this error, and skip applying this block, since the block was already added to the ledger. ## Test Plan Tested manually.
go-algorand v3.1.3-beta
bricerisingalgorand
approved these changes
Nov 18, 2021
Merged
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.
go-algorand 3.1.3-beta re-merge