Closed venuravu closed 5 months ago
Thanks for the report here @venuravu ! This seems to fail around the CursorUtil we use to detect the key passed into the method, not specific to using a different SDK than LaunchDarkly. We would have expected the passed in argument to be a field or constant, and find any references from there. In the sample you're referencing we should have this work if it's a String literal as well; I'll see if that's an easy fix to make.
For this one I was kind of wondering if we needed to make sure we were on the right element prior to checking with CursorUtils
as I was thinking we may be hitting a different method that accepts a Lambda and erroring out on that.
For this one I was kind of wondering if we needed to make sure we were on the right element prior to checking with
CursorUtils
as I was thinking we may be hitting a different method that accepts a Lambda and erroring out on that.
Only seeing this now; how would you change the CursorUtil call? I didn't immediately spot good options there.
For now I'd gone for some defensive short circuiting as the issue failed to replicate in the minimal test:
@timtebeek, the things that I know right now:
ConstantFold.findConstantLiteralValue(c, String.class)
does properly handle a literal, a local variable, or a constant field (in the same class).So there has to be something more about @venuravu's original source that's causing rewrite-analysis to have an issue.
I think one way that we may be able to guard the rewrite-analysis CursorUtils
call is by only invoking it once we have identified the matching method that we want to inspect first, then checking for the value as a nested if
statement.
Maybe something like:
J.MethodInvocation mi = (J.MethodInvocation) super.visitMethodInvocation(method, ctx);
if (methodMatcher.matches(mi)) {
boolean isFirstArgumentFeatureKey =
CursorUtil
.findCursorForTree(getCursor(), mi.getArguments().get(0))
.bind(c -> ConstantFold.findConstantLiteralValue(c, String.class))
.map(featureKey::equals)
.orSome(false);
if (isFirstArgumentFeatureKey) {
// modify
}
}
Even with that said though, I'm really curious what other trait about the original class is tripping up rewrite-analysis because we can get that documented and fixed upstream such that this would be a bit more resilient going forward. Maybe @JLLeitschuh may have a suspicion with the stacktrace snippet that's been provided so far?
Turns out we've encountered that message before:
So likely the thing to replicate here is having a lambda, but we can work around it with a guard as seen abovee.
What version of OpenRewrite are you using?
I am using
How are you running OpenRewrite?
I am using the Gradle plugin, and my project is a multi module project.
What is the smallest, simplest way to reproduce the problem?
rewrite.yml
What did you expect to see?
What did you see instead?
What is the full stack trace of any errors you encountered?
Are you interested in contributing a fix to OpenRewrite?