Adds caching via localstorage to the flag creation form, so that if you
(accidentally) close the form before submitting it, you'll retain (most)
of the same data when you reopen it.
Specifically, we'll store:
- name
- description
- type
- tags
- impression data
We can't store the project as it is now, because it gets overridden by
whatever is in the URL. However, this is probably a good thing. It means
that if you navigate to a different project and open the feature
creation form there, it'll retain everything from the last one, but
it'll use the current project.
The stored data is cleared when you successfully create a feature, so
that you don't get dangling data.
The data is also stored in a shared cache for all projects, so that you
don't have different caches per project.
The behavior of seeding the form is hidden behind a flag (that doesn't
exist yet). We'll still read and write to the cache if the flag is off,
but we won't use it to populate the feature form, so it has no
discernible impact on the user.
## Bug detected 🐛 ... and squashed
Working on this, I came to realize that there was a bug in how the
config button and use feature form hooks interacted. We (in this case
probably me) have assumed that it's fine to use a set for any option
checking in the config buttons. Also, we're using a set to store tags in
the feature form. But objects aren't compared by value in JS, so the set
will happily accept multiple instances of the same tag. Likewise, these
tags won't show up as selected in the dropdown because when the dropdown
checks if the set `has` the value, it's using reference equality.
To get around this, I have normalized the values of the Tags set to
strings (`<type>:<value>`), which are easily comparable.
We can iterate on this later if we need to.
## `useLocalStorageState`
In doing this, I have also made a change to the useLocalStorageState
hook:
the exposed "setState" function now writes to the localstorage
immediately. This is because the useEffect method might not have time to
save the data if the component unmounts (this was the case with the flag
dialog).
However, I have kept the useEffect because it gets run on component
mount and then only when it changes. This means that we will get double
saves to localstorage, but it'll be with the same data, so it's benign.
I've tried out two other uses of the hook (event timeline props and
environment columns in the project flags table) and see no discernible
difference in behavior.
## `useFeatureForm`
I have also made a change to the useFeatureForm hook and removed a
`useEffect` that would reset the name to whatever you passed in as the
initial name if you cleared it out. This essentially meant that you
couldn't clear the name completely, because it would just refill with
the initial name.
As far as I can tell, there is no need to have this sticking around
anymore. The hook is only used in two places: the flag creation dialog
and the flag edit page. The flag edit page doesn't allow you to change
the name anyway and it was causing issues in the dialog. It's likely a
holdover from the way something worked 3 years ago. Both the dialog and
the edit screen seem to work just fine with this change.
I have also changed the function parameters from ordered parameters to
an object. There's so many of them that even you don't think it's a good
idea to use objects when you have multiple params with the same type,
it's just nigh-impossible to remember the order by now.
## Minor changes
Additionally, I came across three issues that were causing react errors,
and have fixed them.
1. we'd forgotten to interpolate a variable and just used the variable
name in a string instead
2. an html attribute that doesn't exist (`aria-role` instead of `role`)
3. Providing a disabled button inside a tooltip. I've seen this one
around for ages and it prevented tooltips from working on disabled
buttons. The solution was wrapping it in a span.
**BREAKING CHANGE**: DEFAULT_ENV changed from `default` (should not be
used anymore) to `development`
## About the changes
- Only delete default env if the install is fresh new.
- Consider development the new default. The main consequence of this
change is that the default is no longer considered `type=production`
environment but also for frontend tokens due to this assumption:
724c4b78a2/src/lib/schema/api-token-schema.test.ts (L54-L59)
(I believe this is mostly due to the [support for admin
tokens](https://github.com/Unleash/unleash/pull/10080#discussion_r2126871567))
- `feature_toggle_update_total` metric reports `n/a` in environment and
environment type as it's not environment specific
BREAKING CHANGE: As part of the preparation for a new major (7.0) this
removes /api/admin/projects/{projectId} endpoint. It has been deprecated
since 5.8, and we don't use it anymore in our frontend.
This removes a strategy that was already deprecated, but only for new
installations.
I tested starting with an installation with this strategy being used and
then updating, and I was still able to edit the strategy, so this should
not impact current users.
On a fresh install the strategy is no longer available.
---------
Co-authored-by: Nuno Góis <github@nunogois.com>
BREAKING CHANGE: This removes the
GET /api/admin/projects/{project}/features/{featureName}/variants
PATCH /api/admin/projects/{project}/features/{featureName}/variants
PUT /api/admin/projects/{project}/features/{featureName}/variants
endpoints
Users should move to environment or strategy specific variant methods
rather than feature level variant methods.
Adding a single table to capture all lifecycle trends data.
One field presents a challenge: `median_time_in_stage_days`. This value
is calculated per `stage`, not per `flag_type`. As a result, we would
need to duplicate the total median time across each flag type. This
isn’t a major issue.
An alternative would be to create a separate table solely for the median
values, but that seems like overkill.
If there are two concurrent requests to create or edit change requests,
two separate ones may be created in parallel. The UI does not currently
handle this scenario, and if additional changes are made, they might be
added to a random existing change request—resulting in a messy and
unpredictable state.
This PR adds a unique index to the `change_requests` table
```
on (created_by, project, environment)
WHERE state NOT IN ('Applied', 'Cancelled', 'Rejected', 'Scheduled').
```
In the extremely rare case where such conflicting data already exists in
a database, the migration will automatically cancel one of the
conflicting change requests.
- added `sideMenuCleanup` flag
- extracted `SecondaryNavigation`, `SecondaryNavigationList` and
`MobileNavigationSidebar` into separate files
- hidden recent projects and flags
- renamed 'Insights' to 'Analytics'
Unleash is being too reactive to events inside Unleash. We should not
update etag if feature is created or tag is added to feature.
This PR adds this condition and adds test for it.
Now we can receive custom metrics, return those for UI and have extra
prometheus endpoint for it.
---------
Co-authored-by: Christopher Kolstad <chriswk@getunleash.io>
Blocks deletion of context fields that are in use and updates the
"active usage" count to exclude use in archived flags.
- Before allowing you to delete a context field, checks if it is in use
by any strategies. If so, returns a 409 error.
- Updates what we count as "in use" to exclude flags that have been
archived.
BREAKING CHANGE: Context fields can no longer be deleted if they are in
use by active (non-archived) flags.
## About the changes
Our health implementation always returns GOOD if the server is up:
beb29f5b5b/src/lib/routes/health-check.ts (L46-L51)
Currently our documentation of the endpoint is misleading saying that it
will return BAD if unable to connect to PostgreSQL
Closes#9965
Vitest Pros:
* Automated failing test comments on github PRs
* A nice local UI with incremental testing when changing files (`yarn
test:ui`)
* Also nicely supported in all major IDEs, click to run test works (so
we won't miss what we had with jest).
* Works well with ESM
Vitest Cons:
* The ESBuild transformer vitest uses takes a little longer to transform
than our current SWC/jest setup, however, it is possible to setup SWC as
the transformer for vitest as well (though it only does one transform,
so we're paying ~7-10 seconds instead of ~ 2-3 seconds in transform
phase).
* Exposes how slow our tests are (tongue in cheek here)
https://linear.app/unleash/issue/2-3564/remove-filterexistingflagnames-feature-flag
We're removing the `filterExistingFlagNames` feature flag since we've
decided we want this to be the default behavior.
We don't need to rush to merge it, just in case we need to disable this
for any reason. However it should also be pretty easy to just revert if
needed.
Changes in tests are a bit tricky since they assumed the previous
behavior where we always registered metrics, even for non existing flag
names. `cachedFeatureNames` is also memoized with a TTL of 10s, so the
easiest way to overcome this was to override `cachedFeatureNames` to
return what we expected. As long as they return the same flag names that
we expect, we're able to register their metrics.
Let me know if you can think of a better approach.
Improves handling of constraints in use that have been deleted.
This change implments a few small changes on both the front and the back
end on how we deal with constraints that have been deleted.
The most important change is on the back end, in the
`/constraints/validate` endpoint. We used to throw here if the
constraint couldn't be found, but the only reason we wanted to look for
the constraint in the db was to check for legal values. Now, instead,
we'll allow you to pass a constraint field that doesn't exist in the
database. We'll still check the values against the operator for
validity, we just don't control legal values anymore (because there
aren't any).
On the front end, we improve the handling by showing the deleted context
filed in the dropdown, both when the selector dropdown is closed and
when it is open. However, if you change the context field, we remove the
deleted field from the list. This seems like a sensible tradeoff. Means
you can't select it if you've deselected it.
We're migrating to ESM, which will allow us to import the latest
versions of our dependencies.
Co-Authored-By: Christopher Kolstad <chriswk@getunleash.io>
Add `getProjectLinkTemplates` method to ProjectStore and corresponding
test. Ideally this should be in a read-model, but let's finish link
templates end to end
Adds support for link templates in projects, allowing reusable URL
patterns with placeholders. Includes validation, database changes,
updated API schemas, and tests.
https://linear.app/unleash/issue/2-3406/hold-unknown-flags-in-memory-and-show-them-in-the-ui-somehow
This PR introduces a suggestion for a “unknown flags” feature.
When clients report metrics for flags that don’t exist in Unleash (e.g.
due to typos), we now track a limited set of these unknown flag names
along with the appnames that reported them. The goal is to help users
identify and clean up incorrect flag usage across their apps.
We store up to 10 unknown flag + appName combinations, keeping only the
most recent reports. Data is collected in-memory and flushed
periodically to the DB, with deduplication and merging to ensure we
don’t exceed the cap even across pods.
We were especially careful to make this implementation defensive, as
unknown flags could be reported in very high volumes. Writes are
batched, deduplicated, and hard-capped to avoid DB pressure.
No UI has been added yet — this is backend-only for now and intended as
a step toward better visibility into client misconfigurations.
I would suggest starting with a simple banner that opens a dialog
showing the list of unknown flags and which apps reported them.
<img width="497" alt="image"
src="https://github.com/user-attachments/assets/b7348e0d-0163-4be4-a7f8-c072e8464331"
/>
