Open ggerade opened 10 months ago
Hi @ggerade,
Thank you for bringing this to our attention! I will dig into this next week and hopefully provide you with an update then.
Hi again @ggerade,
As promised, I'm starting to dig into this now.
I'm a little unsure if I'm investigating the correct problem. I was not able to reproduce it by creating a segment with the anonymous clause you provided; would you be able to give me more detailed steps that led to this issue?
For clarity, I applied the following:
resource "launchdarkly_segment" "anon" {
key = "anonymousSegment"
project_key = launchdarkly_project.test.key
env_key = "test"
name = "anonymous segment"
rules {
clauses {
attribute = "anonymous"
op = "in"
negate = false
values = [
true
]
}
}
}
and it did return "true"
in the values.
We've had segment clauses in place for a while where the terraform for the clause looked like this:
Given that there is no value_type, the type defaults to string. With earlier versions of the nodejs client library there seemed to be a conversion from string to boolean and we would get true back for these situations. But with version 8 of the client library we began getting false back.
If we change these clauses to include
value_type = "boolean"
then all starts working as expected.The LaunchDarkly console UI also does not deal with the string type properly, I noted that when I click edit on a rule setup this way that the drop down for the boolean value is unpopulated. If I choose true from the list and save the rule, then the console converts it to type boolean.
I'm assuming the service wants this to be typed as boolean (reasonable). Ideally the provider would prevent someone from making this misstep and either enforce the type boolean or at least warn if not provided.