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

MappingSubscriber should halt upon any Exception #4205

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

polyatail
Copy link

Motivation and Context

When using SdkPublisher.map, if the mapping function throws an exception that does not inherit from RuntimeException (which often is the case in Kotlin), anything awaiting a result from the Publisher will hang indefinitely, even though the coroutine has ended exceptionally.

Modifications

This change catches and terminates on all exceptions.

Testing

Screenshots (if appropriate)

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)

Checklist

  • I have read the CONTRIBUTING document
  • Local run of mvn install succeeds
  • My code follows the code style of this project
  • My change requires a change to the Javadoc documentation
  • I have updated the Javadoc documentation accordingly
  • I have added tests to cover my changes
  • All new and existing tests passed
  • I have added a changelog entry. Adding a new entry must be accomplished by running the scripts/new-change script and following the instructions. Commit the new file created by the script in .changes/next-release with your changes.
  • My change is to implement 1.11 parity feature and I have updated LaunchChangelog

License

  • I confirm that this pull request can be released under the Apache 2 license

Catching only RuntimeException means anything awaiting a result from a Publisher will hang indefinitely, even after a coroutine has ended exceptionally.
@polyatail polyatail requested a review from a team as a code owner July 18, 2023 23:02
@polyatail
Copy link
Author

Yes, Kotlin does have built-in exceptions that do not inherit from RuntimeException. Even if it didn't, a user could write a piece of code that throws Exception and cause a coroutine to hang indefinitely. This has caused us multiple SEVs at our organization already. Is there a reason to only catch RuntimeException here and not Exception which would be guaranteed to catch everything?

@debora-ito debora-ito added the needs-review This issue or PR needs review from the team. label Aug 3, 2023
@debora-ito debora-ito removed the needs-review This issue or PR needs review from the team. label Aug 24, 2023
@@ -69,7 +69,7 @@ public void onNext(T t) {
if (!isCancelled) {
try {
delegateSubscriber.onNext(mapFunction.apply(t));
} catch (RuntimeException e) {
} catch (Exception e) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we catch Throwable?

Copy link
Author

Choose a reason for hiding this comment

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

Why not? I don't think we can catch too many exceptions here.

Copy link
Member

Choose a reason for hiding this comment

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

@polyatail can you update the PR and add Throwable?

Copy link
Author

Choose a reason for hiding this comment

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

Done.

@kkywalk2
Copy link

kkywalk2 commented Jul 23, 2024

is there any update about this issue?

@polyatail
Copy link
Author

Please merge this.

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.

4 participants