-
Notifications
You must be signed in to change notification settings - Fork 53
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
refactor: Remove net GRPC API #1927
refactor: Remove net GRPC API #1927
Conversation
Codecov ReportAttention:
@@ Coverage Diff @@
## develop #1927 +/- ##
===========================================
+ Coverage 74.60% 74.62% +0.02%
===========================================
Files 234 234
Lines 23116 23044 -72
===========================================
- Hits 17244 17195 -49
+ Misses 4696 4671 -25
- Partials 1176 1178 +2
Flags with carried forward coverage won't be shown. Click here to find out more.
... and 10 files with indirect coverage changes Continue to review full report in Codecov by Sentry.
|
net/node_test.go
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question: I've never seen these test being flaky. I'm not sure the tests are relevant anymore if we don't check the outcome. What do you think caused them to become flaky?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When it failed it was logging an extra line. My guess is that it was always prone to being flaky. Now that we run the parallel test matrix it just appears more often.
testUtils.CreateDoc{ | ||
// This document is created in all nodes | ||
Doc: `{ | ||
"Name": "John", | ||
"Age": 21 | ||
}`, | ||
}, | ||
testUtils.ConfigureReplicator{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
todo: This is changing what the test tests, and if there is flakiness here, it should probably be handled with a WaitForSync
action instead of changing the test my moving when configuration happens.
That said, where have you seen this flakiness? Do you have an issue or an error log?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The CLI tests fail with the original test setup. If the replicator syncs the document before the second node attempts to create it, then it will fail. I will swap it for a WaitForSync
like you suggested.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But only the CLI tests failed/were flaky? That suggests a problem with the production code, not the test.
If the other mutation types are not flaky, and the CLI is, the CLI is not behaving the same way as the others.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe this is due to the CLI being the slowest implementation to test. If you look through the original test steps you can see where the race condition happens. The document syncs from node 0 to node 1 before node 1 has the chance to create it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe this is due to the CLI being the slowest implementation to test.
That does not make sense to me though, as the slowness is outside of the execution bounds in which speed matters (RE race), and if anything the CLI should be more resilient to flakiness here, as there is a larger gap between submitting the Create, and the Update.
Where x = main test thread, y = create async stuff, z = update async stuff, * = mutation type specific x stuff:
x * // Create doc action start
x *
x y //
x y
x y
x y
x y // Create doc action end
x * // Update doc action start
x *
x z
x z
x z
When running CLI tests * may occupy more time, but that should only have the same effect as adding in a wait/sleep, and should reduce the risk of hitting a race condition (where y and z overlap).
From memory I also believe that the ConfigureReplicator
action includes a wait anyway.
TestP2PPeerReplicatorWithUpdate
also seems to run fine with the same create-config-update flow?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Discussed over discord. I misunderstood the nature of the failure, it makes sense to me now, and am happy with this test being changed here. This problem likely affects a bunch of other tests though, and that work should be done in another issue/PR (not here).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I created an issue to start tracking tests with potential race condition #1935
tests/integration/p2p.go
Outdated
// | ||
// A [NonExistentCollectionID] may be provided to test non-existent collection IDs. | ||
CollectionIDs []int | ||
CollectionID int |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
praise: This is a good change, thanks - the test action should reflect the structure of the production operation it represents. AddP2PCollection
takes a single id, so so should the action IMO.
thought (don't bother now): This is however an inedpendantly useful change, that is not just a one-liner, and is independent from the goal of the PR. It should have been in another PR as far as I can see.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure which direction would be better. Remove the option of adding multiple collections in one function call or adding the option to add multiple collections at a time via the CLI/HTTP API. The latter is what I had intended when creating the functionality but the CLI had been implemented with the limitation of one collection at a time (I think I missed that in review).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm happy to consider either option as long as it matches the client API.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll let you decide which one you think creates a better user experience.
defradb client p2pcollection add Users
defradb client p2pcollection add Address
vs
defradb client p2pcollection add Users,Address
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've updated it to support multiple collections like we discussed.
testUtils.ExecuteTestCase(t, test) | ||
} | ||
|
||
func TestP2PSubscribeAddValidThenErroneousCollectionID(t *testing.T) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question: Why have these tests been removed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TestP2PSubscribeAddSingleErroneousCollectionID
tests the same thing since only one subscription at a time is allowed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TestP2PSubscribeAddSingleErroneousCollectionID
does not test that other existing collection-peer subscriptions are unaffected by the attempt to configure a bad collection ID. This test does.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My bad, I had misunderstood these tests. I restored them with one minor modification to make it pass.
@@ -337,10 +341,6 @@ func TestP2PSubscribeAddNone(t *testing.T) { | |||
SourceNodeID: 1, | |||
TargetNodeID: 0, | |||
}, | |||
testUtils.SubscribeToCollection{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
todo: Either the name of this test should be changed slightly, or the test deleted (if this is tested elsewhere, which it might be).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, approving now, assuming Fred's comments are addressed sensibly, as well as/including the log test stuff (maybe split that out to another PR and merge this stuff now?). Plus the one new minor todo from me :)
Thanks Keenan :)
9220ac4
to
c4d386c
Compare
## Relevant issue(s) Resolves #1883 ## Description Blocked by #1927 This PR moves the `client.P2P` implementation from `client.DB` to `net.Node`. This fixes the problems mentioned in the issue above and should increase test coverage of the HTTP and CLI clients. ## Tasks - [x] I made sure the code is well commented, particularly hard-to-understand areas. - [x] I made sure the repository-held documentation is changed accordingly. - [x] I made sure the pull request title adheres to the conventional commit style (the subset used in the project can be found in [tools/configs/chglog/config.yml](tools/configs/chglog/config.yml)). - [x] I made sure to discuss its limitations such as threats to validity, vulnerability to mistake and misuse, robustness to invalidation of assumptions, resource requirements, ... ## How has this been tested? `make test` Specify the platform(s) on which this was tested: - MacOS
## Relevant issue(s) N/A ## Description This PR removes the GRPC API from the net package. The HTTP and CLI interfaces now include this functionality. ## Tasks - [x] I made sure the code is well commented, particularly hard-to-understand areas. - [x] I made sure the repository-held documentation is changed accordingly. - [x] I made sure the pull request title adheres to the conventional commit style (the subset used in the project can be found in [tools/configs/chglog/config.yml](tools/configs/chglog/config.yml)). - [x] I made sure to discuss its limitations such as threats to validity, vulnerability to mistake and misuse, robustness to invalidation of assumptions, resource requirements, ... ## How has this been tested? `make test` Specify the platform(s) on which this was tested: - MacOS
## Relevant issue(s) Resolves sourcenetwork#1883 ## Description Blocked by sourcenetwork#1927 This PR moves the `client.P2P` implementation from `client.DB` to `net.Node`. This fixes the problems mentioned in the issue above and should increase test coverage of the HTTP and CLI clients. ## Tasks - [x] I made sure the code is well commented, particularly hard-to-understand areas. - [x] I made sure the repository-held documentation is changed accordingly. - [x] I made sure the pull request title adheres to the conventional commit style (the subset used in the project can be found in [tools/configs/chglog/config.yml](tools/configs/chglog/config.yml)). - [x] I made sure to discuss its limitations such as threats to validity, vulnerability to mistake and misuse, robustness to invalidation of assumptions, resource requirements, ... ## How has this been tested? `make test` Specify the platform(s) on which this was tested: - MacOS
Relevant issue(s)
N/A
Description
This PR removes the GRPC API from the net package. The HTTP and CLI interfaces now include this functionality.
Tasks
How has this been tested?
make test
Specify the platform(s) on which this was tested: