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.
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
internal/grpcsync: Provide an internal-only pub-sub type API #6167
internal/grpcsync: Provide an internal-only pub-sub type API #6167
Changes from 15 commits
dd64d1d
fdbf826
4f83a06
9e14b9f
d5733fd
b6f2843
c48bce5
42ecca3
85edc36
cb33958
9a6926f
6a7abc7
caf61f1
ba553b5
4b5033d
8b6bd43
cb3d134
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
IIUC, we are trying to check the subscriber receieves the messages in the order they are published. And we know the message that is published in each iteration (which is
i := range numPublished
). Why dont we just check for the message received here and fail if its not the one that is expected?that way we can nix
wantMsg1
andgotMsg1
variables and also fail faster.I usually like the idea of always failing fast as possible in test assertions. Here lets say that the first message itself came out of order, we would have to wait until all the messages are received to fail the test.
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.
In this case, the one sub goroutine is used to call
Publish()
and the other is used to check to see ifts1.OnMessage()
function was called the correct number of times.Both are processed asynchronously.
Also, if we tried to fail faster, it would be more complicated than before.
(I haven't come up with the idea to do yet.)
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.
This one should probably use the
defaultTestTimeout
instead.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.
Why do we fail later in the case of a timeout? I believe its better to t.Fatal whenever the reader goroutine times out and fail fast.
Consider the worst case where onMessage() callback is never invoked. We would have to wait for 10 * 10 ms for the test to fail, where as it could have failed in the first run.
Let me know if there was a different consideration for why we need the isTimeout boolean to check this.
Alternatively, you could use a t.Errorf() when a reader loop times out and then do this after the
wg.Wait()
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.
Whatever we choose, there are trade-offs.
t.Fatal
If we invoke
t.Fatal()
in the goroutine which is called by the main goroutine, the main isn't cancelled.So, we can't use this in sub goroutine.
t.Errof
&t.Failed()
It is more like Golang than using boolean flag. But many error messages would be displayed if there is a timeout in loops and it would make logs difficult to read.
Could you please share your opinion about that🙇♂️
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.
receives the last published message
-- which we know in this case if
numPublished - 1
right? If you go by my comment above, we could also think about nixingwantMsgs2
right?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.
This could be
wantMsgs2 := wantMsgs1[len(wantMsgs1)-1:]
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.
This should be
defaultTestTimeout
and the same applies to the next goroutine. We generally usedefaultTestShortTimeout
only in places where we are waiting for events which we expect to not happen in the test. For example, if we are not expecting a message to arrive from the server, we block for this short timeout and if we receive a message from the server in that timeframe, then we declare an error.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.
Since errCh is initialized with size 1, Wouldn't this be a blocking write if there are multiple timeouts since the channel is only read after
wg.Wait()
?I would recommend not using an
errCh
but instead uset.Error()
ort.Fatal()
in this case? usingt.Error
might help you check if both subscribers failed in this case.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.
This is correct! So we have to fix this problem.
But, as I said the above comment, I'm hesitating using
t.Errorf()
ort.Fatalf()
.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.
Is this not already tests in the previous test case here? Maybe remove that check from the previous test case if you would like to have separate test cases for both
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.
They have different preconditions.
Previous one is tested by calling
pubsub.Subscribe()
at the status that some test subsribers have already added topubsub
.The other one is tested at the status that no subscriber has added to
pubsub
.Considering above, should we remove either?