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

Ensure Sink.contextView is propagated #1450

Merged
merged 10 commits into from
Aug 1, 2024
Merged

Ensure Sink.contextView is propagated #1450

merged 10 commits into from
Aug 1, 2024

Conversation

rozza
Copy link
Member

@rozza rozza commented Jul 16, 2024

When creating a Mono via Mono.create any nested
Monos should have the higher level sinks context view propogated down.

JAVA-5345

When creating a Mono via Mono.create any nested
Monos should have the higher level sinks context view
propogated down.

JAVA-5345
@rozza
Copy link
Member Author

rozza commented Jul 16, 2024

I was unable to create a test to replicate the tracing issue reported in: spring-projects/spring-data-mongodb#4650. However, I manually tested against the repo in ticket and confirmed it works.

@rozza rozza requested review from a team and stIncMale and removed request for a team July 16, 2024 08:38
@stIncMale
Copy link
Member

stIncMale commented Jul 17, 2024

Shouldn't we also do a similar change here? We have a sink there that is given to us, and collectionInfoRetriever.filter creates a new Mono. I.e., shouldn't we do

collectionInfoRetriever.filter(databaseName, cryptContext.getMongoOperation())
        .contextWrite(sink.contextView())
        .doOnSuccess...
        ...
        .subscribe();

If "yes", then there is plenty more places that need the change.

@rozza
Copy link
Member Author

rozza commented Jul 18, 2024

@stIncMale I agree its not helped by not being able to replicate the original test without the full stack. Let me investigate some more.

@rozza rozza marked this pull request as draft July 23, 2024 08:29
@@ -120,7 +120,7 @@ public void subscribe(final Subscriber<? super Void> s) {
return originalError;
})
.then(Mono.error(originalError)))
.doOnCancel(() -> createCancellationMono(terminated, timeout).subscribe())
.doOnCancel(() -> createCancellationMono(terminated, timeout).contextWrite(ctx).subscribe())
Copy link
Member Author

Choose a reason for hiding this comment

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

Cancellation has a side effect - so we need to propagate context there.

Copy link
Member

Choose a reason for hiding this comment

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

Isn't us calling subscribe() here not with a subscriber that was given to us (the s argument), the only thing that requires us to propagate the context from the subscriber s? I suspect that the fact that createCancellationMono has a side-effect (it mutates terminated) is irrelevant. If the side-effect is relevant to context propagation, then could you please explain why?

Copy link
Member Author

Choose a reason for hiding this comment

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

On cancellation of the main Publisher we are calling subscribe() on a async clean up Publisher and we ignore any errors, results / completion.

If the side-effect is relevant to context propagation, then could you please explain why?

The user may have tracing and want to trace from the web app to the driver. Without adding the context here we break that chain and they cannot tie the cleanup operations to a web request.

@rozza rozza marked this pull request as ready for review July 26, 2024 13:53
@rozza rozza requested a review from stIncMale July 26, 2024 13:53
Copy link
Member

@stIncMale stIncMale left a comment

Choose a reason for hiding this comment

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

Just a small code suggestion

@@ -120,7 +120,7 @@ public void subscribe(final Subscriber<? super Void> s) {
return originalError;
})
.then(Mono.error(originalError)))
.doOnCancel(() -> createCancellationMono(terminated, timeout).subscribe())
.doOnCancel(() -> createCancellationMono(terminated, timeout).contextWrite(ctx).subscribe())
Copy link
Member

Choose a reason for hiding this comment

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

Isn't us calling subscribe() here not with a subscriber that was given to us (the s argument), the only thing that requires us to propagate the context from the subscriber s? I suspect that the fact that createCancellationMono has a side-effect (it mutates terminated) is irrelevant. If the side-effect is relevant to context propagation, then could you please explain why?

@rozza rozza requested a review from stIncMale July 29, 2024 09:51
@rozza
Copy link
Member Author

rozza commented Jul 30, 2024

@stIncMale answered your questions - not sure why the reply to createCancellationMono isn't showing inline - but if you click on the code change you see it.

@rozza rozza merged commit f443751 into mongodb:master Aug 1, 2024
57 of 59 checks passed
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.

2 participants