devmode: Fix devmode networking #5182
Conversation
|
go-algorand-sdk test run on these changes https://app.circleci.com/pipelines/github/algorand/go-algorand-sdk/774/workflows/d58a4164-30d3-4c39-af10-4f7b889b3725/jobs/2127 |
Codecov Report
@@ Coverage Diff @@
## master #5182 +/- ##
==========================================
- Coverage 53.51% 52.50% -1.01%
==========================================
Files 439 439
Lines 54985 54987 +2
==========================================
- Hits 29423 28870 -553
- Misses 23271 23783 +512
- Partials 2291 2334 +43
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
| @@ -535,7 +535,10 @@ func (node *AlgorandFullNode) broadcastSignedTxGroup(txgroup []transactions.Sign | |||
| if err != nil { | |||
| logging.Base().Infof("unable to pin transaction: %v", err) | |||
| } | |||
|
|
|||
| // DevMode nodes do not broadcast txns to the network | |||
There was a problem hiding this comment.
nit: this could cause a bit of confusion, because the method name is broadcastSignedTxGroup. Since this method is only referred to in 2 places, there is a way to refactor without too much pain. I.e., you can extract the non-broadcasting logic into its own function (say it's called foo()), then have BroadcastSignedTxGroup call foo() instead of broadcastSignedTxGroup for dev mode - that is.
But again, this is just a nit so feel free to ignore.
There was a problem hiding this comment.
(and we're still stuck with public BroadcastSignedTxGroup regardless of the above)
There was a problem hiding this comment.
I think I like the current implementation better because if I refactor (as below) it would duplicate the conditional and as you stated we're still not broadcasting in some situations from the BroadcastSignedTxGroup method.
func validateAndPin(txgroup []transactions.SignedTxn) (err error) {
...
}
func broadcastSignedTxGroup(txgroup []transactions.SignedTxn) (err error) {
....
}
func BroadcastSignedTxGroup(txgroup []transactions.SignedTxn) (err error) {
if node.devMode {
node.mu.Lock()
defer func() {
// if we added the transaction successfully to the transaction pool, then
// attempt to generate a block and write it to the ledger.
if err == nil {
err = node.writeDevmodeBlock()
}
node.mu.Unlock()
}()
}
if err = validateAndPin(txgroup); err != nil {
return err
}
if !node.devMode {
return broadcastSignedTxGroup(txgroup)
}
}
func BroadcastInternalSignedTxGroup(txgroup []transactions.SignedTxn) (err error) {
if err = validateAndPin(txgroup); err != nil {
return err
}
if !node.devMode {
return broadcastSignedTxGroup(txgroup)
}
}
There was a problem hiding this comment.
Maybe it's simpler to just rename private broadcastSignedTxGroup to be verifyAndNonDevBroadcast (if you can find a better name pls). Regardless, I'm going to approve since this is all just a nit.
There was a problem hiding this comment.
I'm pretty much fine keeping this as a conditional...In general I agree that it would be better to refactor things so that functionality is kept contained in methods relevant to each operational mode. However, that's not how dev mode was implemented--it's just a series of these small conditionals that alter the regular behavior.
In this case, I don't think we're particularly benefitting from splitting this method into 3-4 separate ones, especially since it still requires similar conditionals.
There was a problem hiding this comment.
I could take or leave Zeph's suggestion, I'll leave it to @Eric-Warehime . While it's peculiar for BroadCastSignedTxGroup to succeed without broadcasted anything, we know that DevMode is enabled so it doesn't need to. Somehow that doesn't seem so bad.
|
Since this is a side effect of removing the |
|
For example you could leave devmode with networking disabled by default as it was before, but add a new option for running dev mode + networking to support testing the dev+follow node topology, which I'd argue is a much rarer use case that does not justify the breaking change in #5157. |
Let me think about it...I suspect that disabling broadcasting as I've done here would fix single node devmode networks and break multi-node setups. So I agree we need to probably just disable networking in single node networks in general right? Edit: Disabling broadcasting isn't something which would affect multi-node setups since devmode networks won't operate in the traditional consensus setup. |
|
@cce I've discussed a bit more w/ others and I'm not sure what adding an optional enable/disable networking to devmode gets us. Because of the follower node, we now need networking to work w/ devmode nodes so this fix still needs to happen regardless. In terms of optionally disabling networking in devmode, running it w/ these changes should provide the same experience as running a devmode node w/o networking. While I agree that enabling networking could have more undiscovered bugs than just this one (though I don't know of any), they're all things we would need to fix in the end anyways. |
|
I do not like devmode switch to be scattered across the code. But what are the options?.. |
|
@algorandskiy not sure what other option there is. The functionality needs to be toggled somehow. Short of creating a new node type (i.e. follower node) this seems to be the way to do it. |
Summary
Skip network broadcast of transactions if the node is in devMode.
This fixes a regression that was introduced by 51d5925#diff-375d57e386f20eaa5f09f02bb9d28bfc48ac3dca18d0325f59492208219e5618L188
Test Plan
Sdk tests (formerly failing with
broadcast queue fullsee https://app.circleci.com/pipelines/github/algorand/go-algorand-sdk/771/workflows/d69fed8b-61bd-451b-9315-4f1900af7fdb/jobs/2124 ) all pass locally w/ this commit.