You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Annotation-based cleanup looks for an exact string match on the flag name as specified in the build.gradle.
It doesn't look for the requisite enum name relationship for the specified flag name.
For example,
Case 1: Piranha:FlagName="STALE_FLAG", IsTreated = true,
public enum Experiment {
STALE_FLAG("stale.flag"),
OTHER_FLAG("other.flag");
:
}
@FlagTesting(control = {"stale.flag"})
public void someMethod(...) {
:
}
The likely issue is that we are simply comparing the xpFlagName value for equality with the annotation value (or one of the values in the annotation test list). While this works when both the config and the annotation usage use the same name: either the enum name or the feature flag string literal directly, it breaks in the other two possible combinations as shown above.
Fix:
Add a check where the xpFlagName not only matches the annotation value as only but either matches the value or the enum name as in the enum definition.
We could leverage a coding construct similar to these lines.
The text was updated successfully, but these errors were encountered:
ketkarameya
changed the title
[PiranhaJava] Annotation based cleanup on methods works only when flag name is same as specified in the config
Annotation based cleanup on methods works only when flag name is same as specified in the config
Sep 2, 2022
Description:
Annotation-based cleanup looks for an exact string match on the flag name as specified in the
build.gradle
.It doesn't look for the requisite enum name relationship for the specified flag name.
For example,
Case 1: Piranha:FlagName="STALE_FLAG", IsTreated = true,
Expected: someMethod() gets deleted
Actual: someMethod() isn't deleted
Case 2: Case 1: Piranha:FlagName="stale.flag", IsTreated = true,
Expected: someMethod() gets deleted
Actual: someMethod() isn't deleted
Root cause:
The likely issue is that we are simply comparing the
xpFlagName
value for equality with the annotation value (or one of the values in the annotation test list). While this works when both the config and the annotation usage use the same name: either the enum name or the feature flag string literal directly, it breaks in the other two possible combinations as shown above.Fix:
Add a check where the
xpFlagName
not only matches the annotation value as only but either matches the value or the enum name as in the enum definition.We could leverage a coding construct similar to these lines.
The text was updated successfully, but these errors were encountered: