This repository has been archived by the owner on May 21, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 4
fix: omit reporting EOF errors #19
Merged
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
There are no files selected for viewing
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
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
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -234,12 +234,7 @@ func (s *stream) writeData(wg *sync.WaitGroup) { | |
|
||
err := s.stream.Send(msg.msg) | ||
if err != nil { | ||
s.logger.WithError(err).Error("failed to send data to the stream") | ||
|
||
s.tq.Queue(func() error { | ||
return s.closeWithError(err) | ||
}) | ||
|
||
s.processSendError(err) | ||
return | ||
} | ||
|
||
|
@@ -284,6 +279,17 @@ func (s *stream) writeData(wg *sync.WaitGroup) { | |
} | ||
} | ||
|
||
func (s *stream) processSendError(err error) { | ||
if errors.Is(err, io.EOF) { | ||
s.logger.WithError(err).Debug("skip sending a message stream is cancelled/finished") | ||
err = nil | ||
} | ||
|
||
s.tq.Queue(func() error { | ||
return s.closeWithError(err) | ||
}) | ||
} | ||
|
||
// on registers a listener for a certain event type | ||
func (s *stream) on(event string, listener func(goja.Value) (goja.Value, error)) { | ||
if err := s.eventListeners.add(event, listener); err != nil { | ||
|
@@ -323,10 +329,19 @@ func (s *stream) end() { | |
} | ||
|
||
func (s *stream) closeWithError(err error) error { | ||
s.close(err) | ||
|
||
return s.callErrorListeners(err) | ||
Comment on lines
+332
to
+334
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This means that a user might get multiple errors to be handled. Not certain if that is good or bad ...but I guess we can try it. |
||
} | ||
|
||
// close changes the stream state to closed and triggers the end event listeners | ||
func (s *stream) close(err error) { | ||
if s.state == closed { | ||
return nil | ||
return | ||
} | ||
|
||
s.logger.WithError(err).Debug("stream is closing") | ||
|
||
s.state = closed | ||
close(s.done) | ||
s.tq.Queue(func() error { | ||
|
@@ -336,24 +351,24 @@ func (s *stream) closeWithError(err error) error { | |
if s.timeoutCancel != nil { | ||
s.timeoutCancel() | ||
} | ||
|
||
s.logger.WithError(err).Debug("connection closed") | ||
|
||
if err != nil { | ||
if errList := s.callErrorListeners(err); errList != nil { | ||
return errList | ||
} | ||
} | ||
|
||
return nil | ||
} | ||
|
||
func (s *stream) callErrorListeners(e error) error { | ||
if e == nil { | ||
return nil | ||
} | ||
|
||
rt := s.vu.Runtime() | ||
|
||
obj := extractError(e) | ||
|
||
for _, errorListener := range s.eventListeners.all(eventError) { | ||
list := s.eventListeners.all(eventError) | ||
|
||
if len(list) == 0 { | ||
s.logger.Warnf("no handlers for error registered, but an error happened: %s", e) | ||
} | ||
|
||
for _, errorListener := range list { | ||
if _, err := errorListener(rt.ToValue(obj)); err != nil { | ||
return err | ||
} | ||
|
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.
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 would still prefer to just skip that ...
We can't know if this EOF is because that was what was expected.
If it isn't this is just shuffing it under the rug.
If it is - I feel the user should fix that. Maybe we can not emit it if the WebSocket (js object) is already closed, but doesn't seem like what the user reported to me.
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 according to to this, the real error will be returned with the
RecvMsg
. So EOF in sending context, is not the real error.However, I now I'm thinking that we should not do
closeWithError(nil)
for that case 🤔 since it could hijack the real error reporting. 🤔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 principle, it sounds correct to me
but I'm not getting how this is possible. It sounds like
closeWithError
does not affect directly the read loop which is the place where it is expected to get the real error as you reported.Or is it for the fact that closeWithError is called twice but the second is discarded?
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.
yeah, at the current state,
closeWithError
is designed to discard the second error if the stream is closed. So I think that I need to re-think this and maybe split the responsibilities to actually about the closing and error reporting.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.
What is the expectation, will it land in this PR?
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.
Hey @codebien, there are a couple of actions that I'm going to do, and they are on my list. No worries and no need to push this now.
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.
Okay, I've pushed the commit where tried to address the issue that I've described above:
Regarding the omitting the EOF (in sending), I still believe that's the right thing since as I linked to the grpc's code the real error if that happens is routing to the
RecvMsg