Skip to content

Ensure that all coroutines throwables in core are serializable #3337

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 8 commits into from
Jun 23, 2022
Merged

Ensure that all coroutines throwables in core are serializable #3337

merged 8 commits into from
Jun 23, 2022

Conversation

qwwdfsad
Copy link
Collaborator

Fixes #3328

@qwwdfsad qwwdfsad requested a review from dkhalanskyjb June 22, 2022 08:34
@qwwdfsad qwwdfsad marked this pull request as ready for review June 22, 2022 08:34
dkhalanskyjb
dkhalanskyjb requested changes Jun 22, 2022
View reviewed changes
Copy link
Collaborator

@dkhalanskyjb dkhalanskyjb left a comment

Choose a reason for hiding this comment

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

Could we instead put the test in a separate source set in integration-testing, only adding the guava dependency to that source set?

@qwwdfsad
Copy link
Collaborator Author

qwwdfsad commented Jun 22, 2022 •
edited
Loading

We already have it in Guava integration module and it seems to be fine, isn't it?

@qwwdfsad qwwdfsad requested a review from dkhalanskyjb June 22, 2022 08:45
@dkhalanskyjb
Copy link
Collaborator

For me, it does not, at all, because the test doesn't check the Guava integration, adding a maintenance dependency when there should be none, violating the principle of least surprise.

  • "I added a new exception type in the core library → oh, great, tests for guava broke". Isn't it just the most frustrating when this happens?
  • If we ever decide to fork some integrations, including guava, into, say, a separate project/repository, we'll have to remember to keep the test. I don't think this will ever happen, but putting a test in the guava module makes us think about whether this can happen, because we're tying together testing the core and providing the guava integration.
  • Won't the issue with having to exclude test classes disappear on its own if we change the approach?

@qwwdfsad qwwdfsad force-pushed the fix-serializable-exceptions branch from bd26f72 to 188ab3d Compare June 22, 2022 09:27
@qwwdfsad qwwdfsad requested a review from dkhalanskyjb June 22, 2022 10:00
dkhalanskyjb
dkhalanskyjb reviewed Jun 22, 2022
View reviewed changes
integration-testing/build.gradle Outdated
@@ -23,6 +23,13 @@ dependencies {
}

sourceSets {
test {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Calling this source set test pollutes the other source sets with guava.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Name it withGuavaTest.
I like testWithGuava more but it breaks our naming convention

@qwwdfsad qwwdfsad requested a review from dkhalanskyjb June 22, 2022 10:58
@qwwdfsad qwwdfsad merged commit dfe6f06 into develop Jun 23, 2022
@qwwdfsad qwwdfsad deleted the fix-serializable-exceptions branch June 23, 2022 14:00
pablobaxter pushed a commit to pablobaxter/kotlinx.coroutines that referenced this pull request Sep 14, 2022
@qwwdfsad @pablobaxter
Ensure that all coroutines throwables in core are serializable (Kotli…
064785d 
…n#3337)

* Ensure that all coroutines throwables in core are serializable

Fixes Kotlin#3328
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@dkhalanskyjb dkhalanskyjb Awaiting requested review from dkhalanskyjb

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@qwwdfsad @dkhalanskyjb