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

launchdarkly_feature_flag_environment should make optional attributes optional #38

Closed
bschaeffer opened this issue Aug 26, 2020 · 3 comments

Comments

@bschaeffer
Copy link

bschaeffer commented Aug 26, 2020

Here's a weird one. Take these flags foo and bar where bar wants to define a prereq for foo=true:

resource "launchdarkly_feature_flag" "foo" {
  key = "foo"
  name = "foo"

  variation_type = "boolean"
  variations {
    name = "Enabled"
    value = true
  }
  variations {
    name = "Disabled"
    value = false
  }

  default_on_variation  = false
  default_off_variation = false
}

resource "launchdarkly_feature_flag" "bar" {
  key = "bar"
  name = "bar"

  variation_type = "boolean"
  variations {
    name = "Enabled"
    value = true
  }
  variations {
    name = "Disabled"
    value = false
  }

  default_on_variation  = false
  default_off_variation = false
}

resource "launchdarkly_feature_flag_environment" "bar_prereq" {
  for_each = toset(["test", "production"])
  env_key = each.value
  flag_id = launchdarkly_feature_flag.bar.id
  prerequisites {
    flag_key  = launchdarkly_feature_flag.foo.key
    variation = 0
  }
}

Given the above, I would expect that an apply would leave bar's default and fallthrough variations be Disabled (false).

Actually, terraform ends up creating launchdarkly_feature_flag.bar with the false default/fallthrough, but when applying the launchdarkly_feature_flag_environment.bar_prereq it ends up patching these to true. Here's an example patch from one of our applies:

[
  {
    "op": "replace",
    "path": "/environments/staging/on",
    "value": false
  },
  {
    "op": "replace",
    "path": "/environments/staging/rules",
    "value": []
  },
  {
    "op": "replace",
    "path": "/environments/staging/trackEvents",
    "value": false
  },
  {
    "op": "replace",
    "path": "/environments/staging/prerequisites",
    "value": [
      {
        "key": "foo"
      }
    ]
  },
  {
    "op": "replace",
    "path": "/environments/staging/offVariation",
    "value": 0
  },
  {
    "op": "replace",
    "path": "/environments/staging/targets",
    "value": []
  },
  {
    "op": "replace",
    "path": "/environments/staging/fallthrough",
    "value": {
      "variation": 0
    }
  }
]

I would just expect to see prerequisite patches since that's all wanted to update. Why is it patching rules to empty? What if I wanted terraform to just update a prereq but leave existing rules as is.

@bschaeffer
Copy link
Author

Actually, this seems very dangerous. Given this apply changed the default variation without reporting it in the plan, I imagine it would also update the rules without reporting it in the plan. We want our users to manage the rules outside of terraform, but require prereqs be managed inside. If a user created some rules, then decided they wanted a prereq, this would potentially wipe out all the rules without reporting it to them in the plan.

Am I reading that right?

@ldhenry
Copy link
Collaborator

ldhenry commented Aug 27, 2020

@bschaeffer,

Thanks for bringing this to my attention. I'm going to file this as a high priority bug in our internal issue tracker. I'll be sure to come back here if I need any more info and when we have a fix ready.

Thanks,
Henry

@ldhenry ldhenry mentioned this issue Sep 8, 2020
ldhenry added a commit that referenced this issue Sep 8, 2020
- Fixed a bug where omitted optional `launchdarkly_feature_flag_environment` parameters where making unwanted changes to the resource upon creation. [#38](#38)
@ldhenry
Copy link
Collaborator

ldhenry commented Sep 8, 2020

Hi @bschaeffer,

Thanks again for your help finding this nasty bug. I just published release v1.4.1 with a fix. Please let us know if you have an further issues or feature requests and feel free to re-open this issue if you are still running into trouble.

Thanks,
Henry

@ldhenry ldhenry closed this as completed Sep 8, 2020
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

No branches or pull requests

2 participants