Skip to content

Add tests for context values with scope semantics - #3516

Merged
chemicL merged 4 commits into
3.5.xfrom
test-scopes
Jul 7, 2023
Merged

Add tests for context values with scope semantics#3516
chemicL merged 4 commits into
3.5.xfrom
test-scopes

Conversation

@chemicL

@chemicL chemicL commented Jun 23, 2023

Copy link
Copy Markdown
Member

No description provided.

@chemicL chemicL added the area/context This issue is related to the Context label Jun 23, 2023
@chemicL chemicL self-assigned this Jun 23, 2023
@chemicL
chemicL marked this pull request as ready for review July 5, 2023 11:58
@chemicL
chemicL requested a review from a team as a code owner July 5, 2023 11:58

@OlegDokuka OlegDokuka left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

overall LGTM. Do we wanna add more scenarios. e.g. flatMap, concatMap, and similars?


AtomicReference<ScopedValue> valueInsideFlatMap = new AtomicReference<>();

try (ScopedValue.Scope v1scope1 = v1.open()) {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Do we wanna check as well that if one modifies Scope then nothing wrong happens?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

in what sense do you mean? modifying the v1scope1 or opening a new scope?

@OlegDokuka OlegDokuka Jul 5, 2023

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I was thinking about 2 cases:

  • one call scope close() manually (probably that would break everything and should be illegal 🧐)
  • one opens a scope manually and then closes it manually somewhere else in the chain e.g.
    java var scope = ... mono .doOnSubscibe(__-> scope.set(Scope.open())) .doAfterTerminate(__-> scope.get().close())
    which should be probably legal and should not break anything (but I'm not sure)

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

one call scope close() manually (probably that would break everything and should be illegal 🧐)

Yes, this is illegal and the behaviour should be undefined. Adding tests for it would become some sort of a specification.

one opens a scope manually and then closes it manually somewhere else in the chain e.g.
java var scope = ... mono .doOnSubscibe(-> scope.set(Scope.open())) .doAfterTerminate(-> scope.get().close())
which should be probably legal and should not break anything (but I'm not sure)

In this case it's also illegal in my opinion - the reactive chain is agnostic of Thread switches. Scopes are Thread-bound. If you open a Scope in one Thread, you must close it in the same Thread. Doing that using reactive operators is dangerous, I'd avoid adding a test that shows such a pattern.

@OlegDokuka

OlegDokuka commented Jul 5, 2023

Copy link
Copy Markdown
Contributor

Also, should not this be targeted for 3.5.x?

@chemicL
chemicL changed the base branch from main to 3.5.x July 5, 2023 12:11
@chemicL

chemicL commented Jul 5, 2023

Copy link
Copy Markdown
Member Author

Also, should not this be targeted for 3.5.x?

I actually updated that at the same time you started reviewing. The PR was in draft mode before 3.5.x existed, so it aimed for main initialy.

@chemicL

chemicL commented Jul 6, 2023

Copy link
Copy Markdown
Member Author

overall LGTM. Do we wanna add more scenarios. e.g. flatMap, concatMap, and similars?

I added a test for flatMap in a concurrent scenario to verify that appropriate scopes are created in child threads.

@chemicL

chemicL commented Jul 6, 2023

Copy link
Copy Markdown
Member Author

@OlegDokuka I updated to the latest code from micrometer-metrics/context-propagation#123 which is now finalized.

@chemicL
chemicL merged commit 5358e4d into 3.5.x Jul 7, 2023
@reactorbot

Copy link
Copy Markdown

@chemicL this PR seems to have been merged on a maintenance branch, please ensure the change is merge-forwarded to intermediate maintenance branches and up to main 🙇

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area/context This issue is related to the Context type/enhancement A general enhancement

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants