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

Follow up on #1640 - Add ExecutionInfo to RequestTracker callbacks #1949

Open
wants to merge 2 commits into
base: 4.x
Choose a base branch
from

Conversation

lukasz-antoniak
Copy link
Member

In #1640 we are waiting for author to incorporate our feedback. The intention of this PR is to speed up the process, leaving original author's commit intact and recorded in Git history. Adding ExecutionInfo to RequestTracker is needed to implement OpenTelemetry support (JAVA-3148) and add onStartXXX() callbacks (JAVA-3046).

@@ -36,38 +37,147 @@
public interface RequestTracker extends AutoCloseable {

/**
* @deprecated This method only exists for backward compatibility. Override {@link
* #onSuccess(Request, long, DriverExecutionProfile, Node, String)} instead.
* Invoked each time a request succeeds.
Copy link
Member Author

Choose a reason for hiding this comment

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

I have reordered methods in the interface, so that most recent versions of all distinct methods are placed first. This shall give a better view on their current state.

Copy link
Contributor

@tolbertam tolbertam left a comment

Choose a reason for hiding this comment

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

Was tentatively +1 on #1640, and I think your changes are also good. I like that you retained the original commit, made this easier to review and will also allow us to attribute the change to the original contributor.

The only thing I think we should change is just to add default implementations for getExecutionProfile on the ExecutionInfo interfaces just to retain API compatibility. With that changed I would be a +1.

core/revapi.json Outdated
@@ -6956,6 +6956,16 @@
"old": "method java.lang.Throwable java.lang.Throwable::fillInStackTrace() @ com.fasterxml.jackson.databind.deser.UnresolvedForwardReference",
"new": "method com.fasterxml.jackson.databind.deser.UnresolvedForwardReference com.fasterxml.jackson.databind.deser.UnresolvedForwardReference::fillInStackTrace()",
"justification": "Upgrade jackson-databind to 2.13.4.1 to address CVEs, API change cause: https://github.com/FasterXML/jackson-databind/issues/3419"
},
{
"code": "java.method.addedToInterface",
Copy link
Contributor

Choose a reason for hiding this comment

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

I suppose this would not be a backwards compatible change that we are making in a minor release, which would break the documented following of semver.

I think it would probably be ok to just make default implementations that return null, add a @Nullable annotation, and document that callers should consider use of a custom ExecutionInfo. We could mark removing the default implementation for whenever we next do a major release.

I think this would be pragmatic as it would avoid possibly breaking any third party libraries and requiring another release of the library that the user may not have control of. I'll admit that this seems rather unlikely but I think we should do everything we can to keep semver even if it is somewhat non-optimal.

@@ -368,7 +371,8 @@ private void setFinalResult(
logServerWarnings(callback.statement, executionProfile, executionInfo.getWarnings());
}
} catch (Throwable error) {
setFinalError(callback.statement, error, callback.node, -1);
ExecutionInfo executionInfo = defaultExecutionInfo(callback, -1).build();
Copy link
Contributor

Choose a reason for hiding this comment

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

I know that it worked this way before, but it seems odd to me that we would use -1 for the execution here instead of callback.execution. I guess it's good to leave it this way for consistency like you did, but maybe idea here is "Something unpredictable unexpected happened here that we can't blame on the request itself.

Copy link
Contributor

@tolbertam tolbertam left a comment

Choose a reason for hiding this comment

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

Looks great, thank you!

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