-
Notifications
You must be signed in to change notification settings - Fork 121
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
[DO NOT MERGE] testing flaky tests #1260
Conversation
WalkthroughThe modification involves commenting out the line where Changes
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
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.
Review Status
Actionable comments generated: 1
Configuration used: CodeRabbit UI
Files selected for processing (1)
- protocol/daemons/slinky/client/client_test.go (1 hunks)
Additional comments: 1
protocol/daemons/slinky/client/client_test.go (1)
- 50-50: The changes from lines 50 to 50 involve commenting out the
grpcServer.Serve(ls)
call. While this might have been done to address flaky tests, it also removes the actual server-client interaction from the test. Consider introducing a test flag or environment variable to conditionally start the server, allowing for both isolated unit testing and integrated server-client interaction testing.
go func() { | ||
ls, err := net.Listen("tcp", appFlags.GrpcAddress) | ||
require.NoError(t, err) | ||
err = grpcServer.Serve(ls) | ||
// err = grpcServer.Serve(ls) | ||
require.NoError(t, err) | ||
}() | ||
|
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.
📝 NOTE
This review was outside the diff hunks, and no overlapping diff hunk was found. Original lines [33-33]
The gRPC server is created without specifying credentials, which could lead to insecure communication. To secure the gRPC server, consider adding SSL/TLS credentials. Here's an example of how to add credentials to the server:
+ import "google.golang.org/grpc/credentials"
grpcServer := grpc.NewServer(
+ grpc.Creds(credentials.NewServerTLSFromFile("cert.pem", "cert.key")),
)
Ensure you have the cert.pem
and cert.key
files available in your test environment. This change enhances the security of your gRPC communication during testing.
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.
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.
/* | ||
go func() { | ||
ls, err := net.Listen("tcp", appFlags.GrpcAddress) | ||
require.NoError(t, err) | ||
err = grpcServer.Serve(ls) | ||
require.NoError(t, err) | ||
}() | ||
*/ |
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 changes from lines 47 to 54 involve commenting out the gRPC server setup within a goroutine. While this might be an attempt to address flaky tests, it's essential to investigate the root cause of the flakiness. Disabling parts of the test setup can reduce the test's effectiveness in simulating real-world scenarios. Consider alternative solutions that maintain the integrity of the test setup, such as adjusting timeouts, using more deterministic data, or isolating external dependencies.
Would you like assistance in exploring alternative solutions to address the test flakiness while keeping the test setup intact?
|
||
import ( | ||
"context" | ||
"net" | ||
"testing" | ||
"time" | ||
|
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.
📝 NOTE
This review was outside the diff hunks, and no overlapping diff hunk was found. Original lines [32-32]
The gRPC server is created without specifying credentials, which could lead to insecure communication. Even though this is a test environment, adopting best practices for secure communication is beneficial. Consider adding SSL/TLS credentials to the gRPC server setup. Here's an example of how to add credentials to the server:
+ import "google.golang.org/grpc/credentials"
grpcServer := grpc.NewServer(
+ grpc.Creds(credentials.NewServerTLSFromFile("cert.pem", "cert.key")),
)
Ensure you have the cert.pem
and cert.key
files available in your test environment. This change enhances the security of your gRPC communication during testing.
Changelist
[Describe or list the changes made in this PR]
Test Plan
[Describe how this PR was tested (if applicable)]
Author/Reviewer Checklist
state-breaking
label.indexer-postgres-breaking
label.PrepareProposal
orProcessProposal
, manually add the labelproposal-breaking
.feature:[feature-name]
.backport/[branch-name]
.refactor
,chore
,bug
.