### What
This patches two very subtle bugs in the proxy repository that cause it
to never actually stop polling the db in the background
## Details - Issue 1
We've recently started to get the following output when running `yarn
test`:
` Attempted to log "Error: Unable to acquire a connection
at Object.queryBuilder
(/home/simon/dev/unleash/node_modules/knex/lib/knex-builder/make-knex.js:111:26)`
This seems to occur for every test suite after running the proxy tests
and the full stack trace doesn't point to anything related to the
running tests that produce this output. Running a `git bisect` points to
this commit:
6e44a65c58
being the culprit but I believe that this may have surfaced the bug
rather than causing it.
Layering in a few console logs and running Unleash, seems to point to
the proxy repository setting up data polling but never actually
terminating it when `stop` was called, which is inline with the output
here - effectively the tests were continuing to run the polling in the
background after the suite had exited and jest freaks out that an async
task is running when it shouldn't be. This is easy to reproduce once the
console logs are in place in the `dataPolling` function, by running
Unleash - creating and deleting a front end token never terminates the
poll cycle.
I believe the cause here is some subtlety around using async functions
with timers - stop was being called, which results in the timer being
cleared but a scheduled async call was already on the stack, causing the
recursive call to resolve after stop, resurrecting the timer and
reinitializing the poll cycle.
I've moved the terminating code into the async callback. Which seems to
solve the problem here.
## Details - Issue 2
Related to the first issue, when the proxy service stops the underlying
Unleash Client, it never actually calls destroy on the client, it only
removes it from its internal map. That in turn means that the Client
never calls stop on the injected repository, it only removes it from
memory. However, the scheduled task is `async` and `unref`, meaning it
continues to spin in the background until every other process also
exits. This is patched by simply calling destroy on the client when
cleaning up
## The Ugly
This is really hard to test effectively, mostly because this is an issue
caused by internals within NodeJS and async. I've added a test that
reads the output from the debug log (and also placed a debug log in the
termination code). This also requires the test code to wait until the
async task completes. This is horribly fragile so if someone has a
better idea on how to prove this I would be a very happy human.
The second ugly part is that this is a subtle issue in complex code that
really, really needs to work correctly. I'm nervous about making changes
here without lots of eyes on this
The patched test is currently depending on runtime to take more than a
millisecond to update the tested property. That's not always true and
more so on a fast machine, which makes this test flakey. This forces the
old timestamp to be 100 ms in the past so that the checked property must be at least 100 ms different if the update occurred
<!-- Thanks for creating a PR! To make it easier for reviewers and
everyone else to understand what your changes relate to, please add some
relevant content to the headings below. Feel free to ignore or delete
sections that you don't think are relevant. Thank you! ❤️ -->
## About the changes
<!-- Describe the changes introduced. What are they and why are they
being introduced? Feel free to also add screenshots or steps to view the
changes if they're visual. -->
<!-- Does it close an issue? Multiple? -->
Closes #
[1-743](https://linear.app/unleash/issue/1-743/add-cypress-test-for-notifications-happy-path)
<!-- (For internal contributors): Does it relate to an issue on public
roadmap? -->
<!--
Relates to [roadmap](https://github.com/orgs/Unleash/projects/10) item:
#
-->
### Important files
<!-- PRs can contain a lot of changes, but not all changes are equally
important. Where should a reviewer start looking to get an overview of
the changes? Are any files particularly important? -->
## Discussion points
<!-- Anything about the PR you'd like to discuss before it gets merged?
Got any questions or doubts? -->
---------
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
<!-- Thanks for creating a PR! To make it easier for reviewers and
everyone else to understand what your changes relate to, please add some
relevant content to the headings below. Feel free to ignore or delete
sections that you don't think are relevant. Thank you! ❤️ -->
- Create UpdateTagsSchema
- Create PUT endpoint
## About the changes
<!-- Describe the changes introduced. What are they and why are they
being introduced? Feel free to also add screenshots or steps to view the
changes if they're visual. -->
<!-- Does it close an issue? Multiple? -->
Relates to#
https://linear.app/unleash/issue/1-767/refactor-existing-tag-component-to-also-allow-removing-tags
<!-- (For internal contributors): Does it relate to an issue on public
roadmap? -->
<!--
Relates to [roadmap](https://github.com/orgs/Unleash/projects/10) item:
#
-->
### Important files
<!-- PRs can contain a lot of changes, but not all changes are equally
important. Where should a reviewer start looking to get an overview of
the changes? Are any files particularly important? -->
## Discussion points
<!-- Anything about the PR you'd like to discuss before it gets merged?
Got any questions or doubts? -->
---------
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
## About the changes
Add new methods to simplify the creation of schemas for endpoints with
additional media types (other than `application/json`)
This is a follow-up on exporting an endpoint as `text/csv`
## About the changes
client-metrics-schema is less strict than proxy-metrics-schema because
the former allows empty `instanceId` and also supports dates as
timestamps as well as date-formatted strings.
Using the same schema makes sense to reduce maintainability costs and
it's less error-prone if we need to modify the schema because underlying
the schema they both use the same code.
The reasoning is that proxy metrics should align with our client
metrics. Alternatively, we have new endpoints for edge metrics that will
aggregate and bucket by client.
## Discussion points
Will we ever want to evolve proxy-metrics differently than
client-metrics? I'm under the assumption that the answer is no
### What
Change /edge/metrics endpoint to accept list of ClientMetricsEnv
### Rationale
We originally made the assumption that we probably didn't need to keep
splitting from a map of features into ClientMetricsEnv for bulk, instead
the bulk poster could post ClientMetricsEnv directly. However, Unleash
still expected the old client metrics format with a dictionary of
featurename -> metricsForFeature. This PR changes that to now accept the
list of ClientMetricsEnv (preprocessed data from downstream) instead of
expecting metrics to be in the old single application metric format.
This makes the distinction from the event services clearer.
In enterprise we'll also rename LoginEventService etc to reflect this
rename.
In addition this adds a setting for how long of a retention one should have, defaulting to 336 hours (2 weeks)
## About the changes
Adds more specifics to addon notifications when a flexibleRollout is
updated.
- [x] Specific text for all strategy types
- [x] Add constraint differences for all strategy types
<!-- Does it close an issue? Multiple? -->
Closes [#3140](https://github.com/Unleash/unleash/issues/3140)
## About the changes
Documentation about feature toggle variants per environment
## Discussion points
The version when this will be available is still to be defined.
---------
Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
<!-- Thanks for creating a PR! To make it easier for reviewers and
everyone else to understand what your changes relate to, please add some
relevant content to the headings below. Feel free to ignore or delete
sections that you don't think are relevant. Thank you! ❤️ -->
## About the changes
<!-- Describe the changes introduced. What are they and why are they
being introduced? Feel free to also add screenshots or steps to view the
changes if they're visual. -->
<!-- Does it close an issue? Multiple? -->
Closes #
<!-- (For internal contributors): Does it relate to an issue on public
roadmap? -->
<!--
Relates to [roadmap](https://github.com/orgs/Unleash/projects/10) item:
#
-->
### Important files
<!-- PRs can contain a lot of changes, but not all changes are equally
important. Where should a reviewer start looking to get an overview of
the changes? Are any files particularly important? -->
## Discussion points
<!-- Anything about the PR you'd like to discuss before it gets merged?
Got any questions or doubts? -->
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
<!-- Thanks for creating a PR! To make it easier for reviewers and
everyone else to understand what your changes relate to, please add some
relevant content to the headings below. Feel free to ignore or delete
sections that you don't think are relevant. Thank you! ❤️ -->
## About the changes
<!-- Describe the changes introduced. What are they and why are they
being introduced? Feel free to also add screenshots or steps to view the
changes if they're visual. -->
<!-- Does it close an issue? Multiple? -->
Closes #
<!-- (For internal contributors): Does it relate to an issue on public
roadmap? -->
<!--
Relates to [roadmap](https://github.com/orgs/Unleash/projects/10) item:
#
-->
### Important files
<!-- PRs can contain a lot of changes, but not all changes are equally
important. Where should a reviewer start looking to get an overview of
the changes? Are any files particularly important? -->
## Discussion points
<!-- Anything about the PR you'd like to discuss before it gets merged?
Got any questions or doubts? -->
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
Since `user_notifications` references `notifications`, it makes sense to
drop `user_notifications` before dropping `notifications` and not the
other way around. This should fix the failing tests on Enterprise with
latest main.
Thanks @gastonfournier for the help finding the bug 👍
<!-- Thanks for creating a PR! To make it easier for reviewers and
everyone else to understand what your changes relate to, please add some
relevant content to the headings below. Feel free to ignore or delete
sections that you don't think are relevant. Thank you! ❤️ -->
Creates the `notifications` table and a `user_notifications` join table
## About the changes
<!-- Describe the changes introduced. What are they and why are they
being introduced? Feel free to also add screenshots or steps to view the
changes if they're visual. -->
<!-- Does it close an issue? Multiple? -->
Closes #
[1-720](https://linear.app/unleash/issue/1-720/db-table-for-notifications-and-real-store-with-link-to-event-store-to)
<!-- (For internal contributors): Does it relate to an issue on public
roadmap? -->
<!--
Relates to [roadmap](https://github.com/orgs/Unleash/projects/10) item:
#
-->
### Important files
<!-- PRs can contain a lot of changes, but not all changes are equally
important. Where should a reviewer start looking to get an overview of
the changes? Are any files particularly important? -->
## Discussion points
<!-- Anything about the PR you'd like to discuss before it gets merged?
Got any questions or doubts? -->
---------
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
## About the changes
This makes response time with app names enabled for everyone but also
kept a way of turning it off (kill switch) in case it cause some issues
because of misconfigured app names
## About the changes
Currently, we need to remember of using the email or else the username
of a user when storing into EventStore, because we don't have
[strictNullChecks](https://www.typescriptlang.org/tsconfig#strictNullChecks),
it's error-prone. Fix for a production issue: #3072
This reuses an existing function that also deals with undefined
This PR decouples the forms for creating API tokens and project level
API tokens. The point of having a hook that provides the functionality
for the form is that we can create specific forms that take care of
implementing the logic needed for that form instead of having one form
serving multiple use cases.
<!-- Thanks for creating a PR! To make it easier for reviewers and
everyone else to understand what your changes relate to, please add some
relevant content to the headings below. Feel free to ignore or delete
sections that you don't think are relevant. Thank you! ❤️ -->
## About the changes
<!-- Describe the changes introduced. What are they and why are they
being introduced? Feel free to also add screenshots or steps to view the
changes if they're visual. -->
Define and implements Project api token permissions
Assign permissions to existing roles
Adjust UI to support them
Adjust BE to implement
---------
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
Co-authored-by: Fredrik Strand Oseberg <fredrik.no@gmail.com>
## About the changes
Promoted experimental networkView flag into a configuration that relies
on prometheusApi being configured.
Also, a follow-up on https://github.com/Unleash/unleash/pull/3054 moving
this code to enterprise because it doesn't make sense to maintain this
code in OSS where it's not being used.
## About the changes
Implementation of bulk metrics and registration endpoint. This will be
used by edge nodes to send all collected information.
Types around metrics were improved and `IClientApp.bucket` with type
`any` is no longer needed
---------
Co-authored-by: sighphyre <liquidwicked64@gmail.com>
This PR changes the behavior of checking the incoming token on the
`/api/frontend` path. Instead of using assert resulting in a 500 error
we are throwing an error that is caught by the default controller and
emitted back to the user as JSON.
This should be the correct behaviour, since the endpoint can not give
you any meaningful data without the environment that the API token
holds.
## About the changes
Spotted some issues in logs:
```json
{
"level":"warn",
"message":"Failed to store \"feature-environment-variants-updated\" event: error: insert into \"events\" (\"created_by\", \"data\", \"environment\", \"feature_name\", \"pre_data\", \"project\", \"tags\", \"type\") values (DEFAULT, $1, $2, $3, $4, $5, $6, $7) returning \"id\", \"type\", \"created_by\", \"created_at\", \"data\", \"pre_data\", \"tags\", \"feature_name\", \"project\", \"environment\" - null value in column \"created_by\" violates not-null constraint",
"name":"lib/db/event-store.ts"
}
```
In all other events we're doing the following:
b7fdcd36c0/src/lib/services/segment-service.ts (L80)
So this is just mimicking that to quickly release a patch, but I'll look
into a safer (type-checked) solution so this problem does not happen
again
This PR fixes two issues with events today:
1. Feature toggles "Event log" must include all events, regardless of
the project. This is important as feature toggles may move between
2. Add/remove tags on a feature toggle events should include project id
in order to show up in the project specific event log.
## About the changes
This PR prepares the GA of service accounts: OpenAPI tags, documentation
and flag removal
Relates to [roadmap](https://github.com/orgs/Unleash/projects/10) item:
#2942
---------
Co-authored-by: Nuno Góis <github@nunogois.com>
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
<!-- Thanks for creating a PR! To make it easier for reviewers and
everyone else to understand what your changes relate to, please add some
relevant content to the headings below. Feel free to ignore or delete
sections that you don't think are relevant. Thank you! ❤️ -->
## About the changes
<!-- Describe the changes introduced. What are they and why are they
being introduced? Feel free to also add screenshots or steps to view the
changes if they're visual. -->
<!-- Does it close an issue? Multiple? -->
Closes #
[1-612](https://linear.app/unleash/issue/1-612/first-iteration-of-project-token-management)
<!-- (For internal contributors): Does it relate to an issue on public
roadmap? -->
<!--
Relates to [roadmap](https://github.com/orgs/Unleash/projects/10) item:
#
-->
### Important files
<!-- PRs can contain a lot of changes, but not all changes are equally
important. Where should a reviewer start looking to get an overview of
the changes? Are any files particularly important? -->
## Discussion points
<!-- Anything about the PR you'd like to discuss before it gets merged?
Got any questions or doubts? -->
---------
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
Batch Metrics as a capability developed to support the frontend API to
handle more metrics from SDKs without overloading the DB to much. It has
been running in Unleash Cloud for months and has proven to work quite
nice.
This PR simply removes the flag to make the capability GA, also for
self-hosted users.
## About the changes
This fixes response time metrics with app names when the app just starts
and has zero which is falsy. We want to compare against undefined (which
means the snapshot is not yet ready)
## About the changes
While trying to count only features that are not archived to display the
amount of features of a project, accidentally we filtered out projects
with all features archived (they should show up in the list but with
count of features zero)
This PR takes the project status API a step further by adding the
capability of providing a date to control the selection. We are
currently making calculations based on a gliding 30 day window, updated
once a day. The initial database structure and method for updating the
UI is outlined in this PR.
## About the changes
This PR adds two new functions that is protected by CR. When used
instead of the current setVariantOnEnv and setVariantsOnEnv if the flag
UNLEASH_EXPERIMENTAL_CR_ON_VARIANTS is set, the call is blocked. This
leaves the old functions, which is used from the CR flow in place, and
adds new methods protected by CR.
Also adds e2e tests verifying that the methods will block requests if CR
is enabled for project:environment pair, as well as not block if CR is
not enabled. Tests already in place should confirm that the default
flow, without the flag enabled just works.
## About the changes
Add warnings when we detect something might be wrong with the customer
configuration, in particular with regard to variants configuration
## Rationale
Moving from variants per feature to variants per environment will allow
users to have fine-grained permissions and more control over variants on
different environments: #2254
But because this requires an additional step of copying variants to
other environments, we identified the potential risk of users forgetting
to follow this step. To keep them informed about this, we're introducing
a warning sign after a toggle is enabled when we detect that:
1. The environment is enabled without variants
2. Other enabled environments have variants
This situation would be a problem if you rely on `getVariant` method
from the SDK, because without variants you'll receive the default
variant. Probably, not what you'd expect after enabling the toggle, but
there are situations where this might be correct. Because of the latter,
we thought that adding a warning and letting the user handle the
situation was the best solution.
## UI sketches
Co-authored-by: Nuno Góis <github@nunogois.com>
## About the changes
This PR adds the ability to push variants to multiple environments
overriding the existing variants.
Relates to [roadmap](https://github.com/orgs/Unleash/projects/10) item:
#2254
**Note:** This won't fail if there are variants in other environments, because the operation wouldn't be idempotent. It should have that property because setting variants to 1 or more environments once or twice should not make a difference
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
<!-- Thanks for creating a PR! To make it easier for reviewers and
everyone else to understand what your changes relate to, please add some
relevant content to the headings below. Feel free to ignore or delete
sections that you don't think are relevant. Thank you! ❤️ -->
## About the changes
<!-- Describe the changes introduced. What are they and why are they
being introduced? Feel free to also add screenshots or steps to view the
changes if they're visual. -->
<!-- Does it close an issue? Multiple? -->
Closes #
<!-- (For internal contributors): Does it relate to an issue on public
roadmap? -->
<!--
Relates to [roadmap](https://github.com/orgs/Unleash/projects/10) item:
#
-->
### Important files
<!-- PRs can contain a lot of changes, but not all changes are equally
important. Where should a reviewer start looking to get an overview of
the changes? Are any files particularly important? -->
## Discussion points
<!-- Anything about the PR you'd like to discuss before it gets merged?
Got any questions or doubts? -->
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
Adds support for case for IN and NOT_IN operators
<!-- Thanks for creating a PR! To make it easier for reviewers and
everyone else to understand what your changes relate to, please add some
relevant content to the headings below. Feel free to ignore or delete
sections that you don't think are relevant. Thank you! ❤️ -->
## About the changes
<!-- Describe the changes introduced. What are they and why are they
being introduced? Feel free to also add screenshots or steps to view the
changes if they're visual. -->
<!-- Does it close an issue? Multiple? -->
Closes #
<!-- (For internal contributors): Does it relate to an issue on public
roadmap? -->
<!--
Relates to [roadmap](https://github.com/orgs/Unleash/projects/10) item:
#
-->
### Important files
<!-- PRs can contain a lot of changes, but not all changes are equally
important. Where should a reviewer start looking to get an overview of
the changes? Are any files particularly important? -->
<img width="1547" alt="Screenshot 2023-01-18 at 11 35 10"
src="https://user-images.githubusercontent.com/104830839/213136158-25c525c8-de82-423b-93d1-5ae6eb8469fa.png">
## Discussion points
<!-- Anything about the PR you'd like to discuss before it gets merged?
Got any questions or doubts? -->
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
This PR moves the getProjectOverview method out from the project health
controller. It doesn't make sense that this method lives here anymore,
as over time it has grown into method that relays all information about
a single project. It makes more sense that this now lives on the root of
the project api. Also removes unwanted duplication of getProjectOverview
from the project-service and the project-health-service.
## About the changes
When exporting v3, for variants backward compatibility, we need to find
one featureEnvironment and fetch variants from there.
In cases where the default environment is disabled (therefore does not
get variants per environment when added), it can be still be selected
for the export process. Therefore variants don't appear in the feature
when they should be there.
An e2e test that fails with the previous implementation was added to
validate the behavior
This comes from our support ticket 404
## About the changes
Introduce a snapshot version of instanceStats inside
instance-stats-service to provide a cached state of the statistics
without compromising the DB.
### Important notes
Some rule-of-thumb applied in the PR that can be changed:
1. The snapshot refresh time
2. The threshold to report appName with the metrics
## Discussion points
1. The snapshot could be limited to just the information needed (things
like `hasOIDC` don't change until there's a restart), to optimize the memory usage
3. metrics.ts (used to expose Prometheus metrics) has a [refresh
interval of
2hs](2d16730cc2/src/lib/metrics.ts (L189-L195)),
but with this implementation, we could remove that background task and
rely on the snapshot
4. We could additionally update the snapshot every time someone queries
the DB to fetch stats (`getStats()` method), but it may increase
complexity without a significant benefit
Co-authored-by: Mateusz Kwasniewski <kwasniewski.mateusz@gmail.com>
Co-authored-by: Simon Hornby <liquidwicked64@gmail.com>
## About the changes
This is a follow-up on #1953
This implementation generalizes how we fetch some standard parameters
from the query parameters or request body.
## Discussion points
Unfortunately, we have not used standard names for our APIs and one
example is our `projectId` (in some cases we just used `project`).
Ideally, we're only using one way of sending these parameters either
`projectId` or `project` (same applies to `environment` vs
`environmentId`).
If both parameters are present, due to historical reasons, we'll give
precedence to:
- `projectId` over `project`
- `environment` over `environmentId`
In the presence of both query parameters and body, we'll give precedence
to query parameters also for historical reasons.
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
<!-- Thanks for creating a PR! To make it easier for reviewers and
everyone else to understand what your changes relate to, please add some
relevant content to the headings below. Feel free to ignore or delete
sections that you don't think are relevant. Thank you! ❤️ -->
This PR fixes the admin feature schema by moving the `strategies`
(featureStrategySchema) from the root of `feature` object to
`feature.environment`
## About the changes
<!-- Describe the changes introduced. What are they and why are they
being introduced? Feel free to also add screenshots or steps to view the
changes if they're visual. -->
<!-- Does it close an issue? Multiple? -->
Closes #
<!-- (For internal contributors): Does it relate to an issue on public
roadmap? -->
<!--
Relates to [roadmap](https://github.com/orgs/Unleash/projects/10) item:
#
-->
### Important files
<!-- PRs can contain a lot of changes, but not all changes are equally
important. Where should a reviewer start looking to get an overview of
the changes? Are any files particularly important? -->
## Discussion points
<!-- Anything about the PR you'd like to discuss before it gets merged?
Got any questions or doubts? -->
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
## About the changes
This uses log-level warning so we can turn off the log without turning
off all error logs. This could potentially be tweaked further by using
log categories in the log configuration.
Closes#2057
## About the changes
According to our docs, we only support up to 1 decimal place for
weights. This is to use integers to represent the percentages (we divide
them by 10) and supporting more decimals results in bad maths due to
floating point arithmetics.
This PRs adds Frontend and Backend validations to enforce this
restriction
Closes#2222
## Discussion points
Should we reconsider supporting more decimal places, that door remains
open, but for now we'll just adhere to our documentation because that
change would require some development.
## About the changes
When exporting features one is normally also interested in disabled
features, so they are also included in the export file, while the
variants are not. I do not see a good reason for that, so this PR
removes the check and exports the variants then as well.
I could also add an option as well, but as long as there is no good
reason for ignoring the variants I would just export them with the
features.
This PR adds tests on #2719Closes#2719
Co-authored-by: Martin Joehren <martin.joehren@esailors.de>
We have experienced side-effects where the import was unexpected and
resulted in environments thought to be removed. This had the unexpected
side-effect of also deleting API keys for some environments not part of
the import file.
This commit removes the ability of the state-service to mutate api keys
directly. There is no compelling reasons why we should remove API keys
as part of an import query.
Co-authored-by: Gastón Fournier <gaston@getunleash.ai>
Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
## About the changes
To avoid showing too much data in the traffic screen, limit the number
of results to `topk`.
## Discussion points
Top 10 is a rule of thumb, but maybe we could do top 25. Until we gather
more data, I believe this should be good enough
## What
Previously when importing strategies we've used the same data type we've
used for creating strategies (the minimal, a name, an optional
description, optional parameters and an optional editable column). This
meant that exporting strategies and then importing them would reactivate
deprecated strategies. This PR changes to allow the import to preserve
all the data coming in the export file.
## Tests
Added four new tests, two new unit tests using our fake stores and two
new e2e tests. Interestingly the ones in the fake store ran green before
this change as well, probably because we just insert the parsed json
object in the fake store, whereas the real store actually converts the
object from camelCasing to the postgresql snake_casing standard.
## Discussion points:
### Mismatch between fake and real stores
This is inevitable since storing things in javascript arrays vs saving
in a real database will have some differences, but this again shows the
value of our e2e tests.
### Invariants
Should we see if we can add some invariants to our import/export so that
we can write some proptests for it? One candidate is commutativity of
import/export. On a fresh database importing and then exporting should
yield the same file that was imported provided all flags are turned on.
Candidate for Q1 improvement of import/export.
Adding stricter types to `FlagResolver` can possibly help improve our DX
- Help us prevent errors like typos, guide us to correctly add a flag
when needed, and warn us of stray checks whenever we do a clean up at a
later stage.
## About the changes
This PR improves our queries to Prometheus (instead of making multiple queries do only one) and improves the UI and the code.
The reports aggregate all HTTP methods (GET, POST, PUT, DELETE, OPTIONS, HEAD and PATCH) without distinction under the same "endpoint" (a relative path inside unleash up to a certain depth)
Co-authored-by: Nuno Góis <nuno@getunleash.ai>
## About the changes
This metric will expose an aggregated view of how many client
applications are registered in Unleash. Since applications are ephemeral
we are exposing this metric in different time windows based on when the
application was last seen.
The caveat is that we issue a database query for each new range we want
to add. Hopefully, this should not be a problem because:
a) the amount of ranges we'd expose is small and unlikely to grow
b) this is currently updated at startup time and even if we update it on
a scheduled basis the refresh rate will be rather sparse
## Sample data
This is how metrics will look like
```
# HELP client_apps_total Number of registered client apps aggregated by range by last seen
# TYPE client_apps_total gauge
client_apps_total{range="allTime"} 3
client_apps_total{range="30d"} 3
client_apps_total{range="7d"} 2
```
## About the changes
The deprecated /api/admin/features endpoint supported querying with tag
and namePrefix parameters.
This PR adds this functionality to
/api/admin/projects/<project>/features as well, allowing to replicate
queries that used to work.
Closes#2306
### Important files
src/lib/db/feature-strategy-store.ts
src/test/e2e/stores/feature-strategies-store.e2e.test.ts
## Discussion points
I'm extending our query parameters support for
/api/admin/projects/<projectId>/features endpoint. This will be
reflected in our open-api spec, so I also made an
adminFeaturesQuerySchema for this.
Also, very open for something similar to what we did for the modifyQuery
for the archived parameter, but couldn't come up with a good way to
support subselects using the query builder, it just ended up blowing the
stack. If anyone has a suggestion, I'm all ears.
Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
## What
We've already added the backend for this. This is the initial work for
drawing a chart for instance traffic in the frontend. It requires the environment variable `PROMETHEUS_API` set to a valid prometheus-query-language (promql) supported backend, such as Prometheus itself or Victoria Metrics. Besides, at the moment we're hiding this functionality behind the flag `UNLEASH_EXPERIMENTAL_NETWORK_VIEW` which has to be set to true
Co-authored-by: Christopher Kolstad <chriswk@getunleash.ai>
Co-authored-by: Gastón Fournier <gaston@getunleash.ai>
