Skip to content
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

the netty unicast processor is not emitting errors for downstream subscribers #6074

Merged
merged 3 commits into from
Sep 6, 2021

Conversation

rawilder
Copy link
Contributor

related to: #6062

@graemerocher
Copy link
Contributor

Needs a test

emitter.error(t);
}

@Override
protected void doOnComplete() {
for (UnicastProcessor subject : subjects.values()) {
subjects.values().forEach(subject -> {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't change to functional style

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry about that, force of habit

@@ -827,16 +827,17 @@ protected void doOnNext(Object message) {
@Override
protected void doOnError(Throwable t) {
s.cancel();
subjects.values().forEach(subject -> subject.onError(t));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A simple for loop as is below is preferred here

@rawilder
Copy link
Contributor Author

rawilder commented Sep 1, 2021

This will sound crazy but I can't replicate the kotlin failure via a test (see here: https://github.com/rawilder/mn-multi-file-upload/pull/1/files).

It's only happening via server start -> manual request. Which means I'd have to inject a failure somehow into the onNext function of RoutingInBoundHandler:buildSubscriber which I really am not sure how to do. I was trying to find some component I could mock and make throw but nothing stood out as obvious or not breaking other bits. Any ideas?

@graemerocher graemerocher added this to the 3.0.1 milestone Sep 2, 2021
@jameskleeh
Copy link
Contributor

@rawilder Try moving the test which should fail into its own class. Because tests are executing before the new tests they are not the first request to the server which is the case where we saw the failure

@rawilder
Copy link
Contributor Author

rawilder commented Sep 2, 2021

@jameskleeh I moved the two tests to their own class locally and both succeeded. Would you like me to still push that to separate them out?

@jameskleeh jameskleeh merged commit 39ed6d5 into micronaut-projects:3.0.x Sep 6, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants