This triggers when we update or overwrite variants, and will include the
previous variants and the new variants.
Co-authored-by: Ivar Østhus <ivarconr@gmail.com>
* fix: sort variants on output
We found that for existing variants, the sorting by name wasn't applied, so the index in the patches were wrong. This PR adds the sort also when we're getting variants as part of the getFeature call, not just when we're getting the variants. This should make the UX consistent, and prevent our patches from hitting the wrong index in the variants array.
Co-authored-by: Youssef Khedher <khedher.youssef@hotmail.fr>
* task: Ban changes to variants through feature
After adding the new `/variants` endpoint for features we now have a way
to access control adding/modifying variants, so the /:featureName
endpoint should no longer allow editing/adding variants.
This removes variants as a known field from the featureMetadata schema
and tells joi to stripUnknown, thus making sure we never include
variants in the initial creation or future update calls.
For the old features v1 API we allow it to declare that it has already
validated the data coming with its own schema, so we should use the data
we get from it. Thus keeping the old v1 functionality intact
Co-authored-by: Simon Hornby <simon@getunleash.ai>
- Since the archived toggles are not visible in the health dashboard,
including them in the health rating calculation makes for some really
confusing dashboards. This PR makes sure we only include non-archived
toggles when calculating health.
Add a new .../:feature/variants API
This adds
- `GET /api/admin/projects/:projectId/features/:featureName/variants` which returns
```json
{ version: '1', variants: IVariant[] }
```
- `PATCH /api/admin/projects/:projectId/features/:featureName/variants` which accepts a json patch set and updates the feature's variants field and then returns
```json
{ version: '1', variants: IVariant[] }
```
- `PUT /api/admin/projects/:projectId/features/:featureName/variants`
which accepts a IVariant[] and overwrites the current variants list for the feature defined in :featureName and returns
```json
{ version: '1', variants: IVariant[] }
- This also makes sure the total weight of all variants is == 1000
- Validates that there is at least 1 'variable' variant if there are variants
- Validates that 'fix' variants total weight can't exceed 1000
- Adds tests for all these invariants.
Co-authored-by: Simon Hornby <simon@getunleash.ai>
* fix: prevent deadlock for batchinserting usage metrics
In client metrics v2 we utilize postgres to count the usage
across a few dimentions (featureName, app_name, environment).
It turns out that if the UPDATE values are not executed in a predictable
order we can end up in a deadlock scenario with postgresql.
In this fix we thus sort the metrics on the feature_name, app_name and
envrionment, to make sure they always are executed in a predictabel
order, and thus avoiding independent inserts colliding in to a deadlock
waiting for eachother.
* fix: tests cannot assume order
- In order for a feature toggle to be allowed to change project, the
target project must have the same enabled environments.
- If the feature toggle has an environment which is not in use that does
not exist in target project, this is ok.
Co-authored-by: Fredrik Strand Oseberg <fredrik.no@gmail.com>
Co-authored-by: Fredrik Strand Oseberg <fredrik.no@gmail.com>
Adds a new way of handling usage metrics where we push it directly to the database and performs aggregation on the fly. All metrics are aggregated in to buckets of hours. We will for now store metrics for the 48 hours with the following dimensions:
- featureName
- projectName
- envrionment
- yes (the actual count)
- no (the actual count)
* feat: add new more specific feature/environment events to addons
* Updated strategy change text
* Update all three addon messages for strategy
* Link to new features view for strategy change text
Co-authored-by: Ivar Conradi Østhus <ivarconr@gmail.com>
