-
Notifications
You must be signed in to change notification settings - Fork 406
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
fix: incorrect negative value conversion #4316
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
1 Skipped Deployment
|
|
|
|
|
|
Uffizzi Preview |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm... I tend to agree with this change... but I have a feeling it's a breaking change, right? If people re-save a feature with a negative value it will immediately start returning as an integer in the SDKs.
For reference, I've just checked the production database and we have ~60 such cases.
Hmm yeah, we've fixed this conversion before but I think that only affected people experiencing an issue. It depends on what language SDK they are using (we should maybe track this in headers). JavaScript will actually work with both, because JavaScript. |
@matthewelwell Could you share that dataset/query? I'd like to evaluate our options to move forward based on that. |
I've done this in Slack FYI @rolodato . |
I've reviewed the data and there's about 10 organisations, viewable here: https://metabase.flagsmith.com/question/9-features-with-negative-numbers-as-strings. Some of them do have these values set in production so we can't just ship this change as-is, unfortunately. I can think of a few paths forward:
IMO, option 2 is ideal UX until if/when we ship explicit feature value types, but option 3 might be a better effort/reward compromise based on how few SaaS users are actually affected by this. Option 3 is not as much implementation effort and is less risky (no user interaction or manipulating feature values on behalf of users). I'll leave this decision to @kyle-ssg since you'll probably write the code for the actual solution :) |
I've been reviewing/attempting 2 and I think it's a big change with lots of code considering the amount of people this will temporarily affect. Especially when this considers change requests and feature versioning. I'd be inclined to go with 3. |
Docker builds report
|
Saving this feature will convert its value from a string to a | ||
number. If you wish to preserve this value as a string, please | ||
save it via our{' '} | ||
<a href='https://api.flagsmith.com/api/v1/docs/#/api/api_v1_environments_featurestates_update'> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor nit - suggest wording this as please save it using the Admin API
for consistency with other docs. LGTM, good stuff 🙏
Thanks for submitting a PR! Please check the boxes below:
pre-commit
to check lintingdocs/
if required so people know about the feature!Changes
Negative ints were being sent as strings to the api when saving a feature.
How did you test this code?
Saved a feature with the value -1