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

Payload for Webhook Emitted on Flag Reset for Identity is Inaccurate #2102

Open
1 task done
jjorissen52 opened this issue Apr 6, 2023 · 4 comments
Open
1 task done
Assignees
Labels
bug Something isn't working

Comments

@jjorissen52
Copy link

jjorissen52 commented Apr 6, 2023

Describe the bug
When a feature is toggled for an identity to override an environment default, and later that feature is reset for the identity, the payload of emitted webhook is not accurate.

To Reproduce

Steps to reproduce the behavior:

  1. Have a feature which defaults to off
  2. Toggle the feature on for an identity (webhook is emitted)
  3. Reset the feature for the identity (webhook is emitted)
  4. Observe the emitted webhook payload incorrectly describes the new_state: data.new_state.enabled == true.

Expected behavior

  1. The new_state in the webhook payload should correspond to the default state of the feature for the environment

How are you running Flagsmith?

  • SaaS at flagsmith.com

Additional context

I first brought this up in #148, so I'll just repeat my comment verbatim below because that issue was closed. I want to emphasize, however, that the problem statement of #148 is not true. Webhooks are emitted when someone resets the state for an identity! #148 was labeled as tech debt to introduce a desired feature, but I am opening this issue as a bug because the functionality exists but is incorrect.


The behavior I'm seeing here is that a webhook is sent when a feature is reset for an identity, however, the resulting payload shows enabled: true when the default is false. Here's an example (with some redactions) of a webhook payload emitted when resetting a feature that defaults to off:

data:
  changed_by: me
  new_state:
    enabled: true
    feature:
      created_date: 2021-10-28T15:41:35.074466Z
      default_enabled: false
      description: Maintenance Mode
      id: 13637
      initial_value: null
      name: '@perm:maintenance-mode'
      type: STANDARD
    feature_segment: null
    feature_state_value: null
    identity: 49679244
    identity_identifier: me
  previous_state:
    enabled: true
    feature:
      created_date: 2021-10-28T15:41:35.074466Z
      default_enabled: false
      description: Maintenance Mode
      id: 13637
      initial_value: null
      name: '@perm:maintenance-mode'
      type: STANDARD
    feature_segment: null
    feature_state_value: null
    identity: 49679244
    identity_identifier: me
  timestamp: 2023-04-04T17:43:55.031610Z
event_type: FLAG_UPDATED

Note that data.new_state.enabled == true even though data.new_state.feature.default_enabled == false. The expectation is that data.new_state.enabled == data.new_state.feature.default_enabled when resetting a feature for an identity.

@jjorissen52 jjorissen52 added the bug Something isn't working label Apr 6, 2023
@matthewelwell
Copy link
Contributor

Thanks for this @jjorissen52, we will review and update here once we have looked into it.

@matthewelwell
Copy link
Contributor

@jjorissen52 - I am not able to replicate this. Are you able to confirm whether your project is using Edge or Core? You should be able to tell this by checking the label underneath your project name in the top left of the dashboard.

@matthewelwell
Copy link
Contributor

matthewelwell commented Apr 11, 2023

I've been able to reproduce this on a Core project. I've also reopened and updated #148 as the issue relates to Edge projects only.

@jjorissen52
Copy link
Author

@matthewelwell Apologies for the delay, yes it's a Core project.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants