## About the changes
Add some **info** logs prefixed with `[etag]` so que can control them
and with this investigate the increase in traffic after the new etag
implementation.
This PR cleans up the projectListViewToggle flag. These changes were
automatically generated by AI and should be reviewed carefully.
Fixes#10526
## 🧹 AI Flag Cleanup Summary
This change removes the `projectListViewToggle` feature flag and
hardcodes its
behavior. The feature, which allows toggling between card and list views
for
projects, is now permanently enabled.
### 🚮 Removed
- **Flag Definitions**
- Removed `projectListViewToggle` from `src/server-dev.ts`,
`src/lib/types/experimental.ts`, and
`frontend/src/interfaces/uiConfig.ts`.
- **Hooks & Conditionals**
- Removed `useUiFlag('projectListViewToggle')` calls from
`ProjectGroup.tsx`
and `ProjectList.tsx`.
- Removed conditional rendering logic based on the flag in
`ProjectGroup.tsx`
and `ProjectList.tsx`.
### 🛠 Kept
- **Project List View**
- The project list view functionality is now always available for
non-OSS
versions of Unleash.
- The `ProjectsListViewToggle` component is now always rendered when not
in an
OSS environment.
### 📝 Why
The `projectListViewToggle` feature flag was marked as completed and its
intended outcome was to be kept. The code has been updated to reflect
this by
removing the flag and making the feature a permanent part of the
application.
This simplifies the codebase by removing dead code paths and feature
flag
checks.
Co-authored-by: unleash-bot <194219037+unleash-bot[bot]@users.noreply.github.com>
This PR cleans up the paygInstanceStatsEvents flag. These changes were
automatically generated by AI and should be reviewed carefully.
Fixes#10507🧹 AI Flag Cleanup Summary
This change removes the paygInstanceStatsEvents feature flag. The
changes
involve removing its definition from the codebase.
⚠️ No conditional logic for paygInstanceStatsEvents was found in the
provided
files. The logic may exist in another repository, and this change only
removes
the flag's definition.
🚮 Removed
• Configuration
• Removed paygInstanceStatsEvents flag definition from
src/lib/types/experimental.ts.
• Changelog
• Added an entry for the flag cleanup under a new [Unreleased] section
in
CHANGELOG.md.
📝 Why
The paygInstanceStatsEvents feature flag was marked as completed with
the
outcome "kept". This cleanup removes the flag's definition, following
our
standard process for retiring feature flags.
---------
Co-authored-by: unleash-bot <194219037+unleash-bot[bot]@users.noreply.github.com>
Co-authored-by: Thomas Heartman <thomas@getunleash.io>
This PR cleans up the paygTrialEvents flag. These changes were
automatically generated by AI and should be reviewed carefully.
Fixes#10506
## 🧹 AI Flag Cleanup Summary
The `paygTrialEvents` feature flag has been removed from the codebase.
Since no
conditional logic using this flag was found in this repository, only the
flag's
definition and configuration were removed.
⚠️ **Warning:** No conditional logic for this flag was found in the
provided
files. The logic may exist in another repository.
### 🚮 Removed
- **Configuration**
- Removed `paygTrialEvents` from the `IFlagKey` type in
`src/lib/types/experimental.ts`.
- Removed the `paygTrialEvents` flag definition from
`src/lib/types/experimental.ts`.
- Removed `paygTrialEvents` from the development server configuration in
`src/server-dev.ts`.
### 🛠 Kept
- **Feature**
- The `paygTrialEvents` feature is considered enabled by default now.
### 📝 Why
The feature flag `paygTrialEvents` was marked as completed with an
outcome of
"kept". The cleanup involves removing the flag and its related
definitions.
Co-authored-by: unleash-bot <194219037+unleash-bot[bot]@users.noreply.github.com>
Co-authored-by: Thomas Heartman <thomas@getunleash.io>
This PR deprecates `CLIENT` api token type in favor of `BACKEND` but
both will continue working.
Also replaces:
- `INIT_CLIENT_API_TOKENS` with `INIT_BACKEND_API_TOKENS`. The former is
kept for backward compatibility.
This PR cleans up the createFlagDialogCache flag. These changes were
automatically generated by AI and should be reviewed carefully.
Fixes#10504
## 🧹 AI Flag Cleanup Summary
This change removes the `createFlagDialogCache` feature flag, making its
functionality permanent. The create-feature-flag dialog will now always
cache
its state in local storage.
### 🚮 Removed
- **TypeScript Definitions**
- Removed `createFlagDialogCache` from `UiFlags` in
`frontend/src/interfaces/uiConfig.ts`.
- Removed `createFlagDialogCache` from `IFlagKey` in
`src/lib/types/experimental.ts`.
- **Flag Configuration**
- Removed the `createFlagDialogCache` flag definition from
`src/lib/types/experimental.ts`.
- **Conditional Logic**
- Removed the `useUiFlag` hook and conditional logic for caching in
`frontend/src/component/project/Project/PaginatedProjectFeatureToggles/ProjectFe
atureTogglesHeader/CreateFeatureDialog.tsx`.
### 🛠 Kept
- **Feature Functionality**
- The feature of caching the create-flag dialog's form state in local
storage
is now always enabled.
### 📝 Why
The `createFlagDialogCache` feature has been successfully rolled out and
is now
considered stable. This cleanup removes the obsolete feature flag and
hardcodes
the enabled behavior, simplifying the codebase.
Co-authored-by: unleash-bot <194219037+unleash-bot[bot]@users.noreply.github.com>
Co-authored-by: Thomas Heartman <thomas@getunleash.io>
This PR cleans up the lifecycleMetrics flag. These changes were
automatically generated by AI and should be reviewed carefully.
Fixes#10505
---------
Co-authored-by: unleash-bot <194219037+unleash-bot[bot]@users.noreply.github.com>
Co-authored-by: Thomas Heartman <thomas@getunleash.io>
This PR cleans up the crDiffView flag. These changes were automatically
generated by AI and should be reviewed carefully.
Fixes#10484🧹 AI Flag Cleanup Summary
This PR removes the crDiffView feature flag and its associated legacy
components
for displaying changes in a Change Request. The flag has been enabled
and the
new diff view is now permanent.
This involved removing the feature flag from the configuration and code,
deleting several legacy components, and updating the components that
used them
to only use the new versions.
🚮 Removed
• Feature Flag Logic
• All checks for the crDiffView flag.
• The flag definition in uiConfig.ts, experimental.ts, and
server-dev.ts.
• Legacy Components
• LegacyStrategyChange.tsx
• StrategyTooltipLink.tsx
• LegacyReleasePlanChange.tsx
• SegmentTooltipLink.tsx
• LegacySegmentChangeDetails.tsx
• LegacyArchiveFeatureChange from ArchiveFeatureChange.tsx
• LegacyDependencyChange from DependencyChange.tsx
• LegacyToggleStatusChange from ToggleStatusChange.tsx
🛠 Kept
• New Components
• The new change request diff view components (StrategyChange,
ReleasePlanChange, etc.) are now used directly.
• The UI for displaying changes in a Change Request now consistently
uses
the improved diff view.
📝 Why
The crDiffView feature flag was deemed complete and ready for permanent
implementation. The cleanup follows standard procedure to remove the
flag and
associated dead code, simplifying the codebase and making it easier to
maintain.
This change makes the improved diff view for change requests the only
available
view.
---------
Co-authored-by: unleash-bot <194219037+unleash-bot[bot]@users.noreply.github.com>
Co-authored-by: Thomas Heartman <thomas@getunleash.io>
This PR cleans up the improvedJsonDiff flag. These changes were
automatically generated by AI and should be reviewed carefully.
Fixes#10483
## 🧹 AI Flag Cleanup Summary
This PR removes the `improvedJsonDiff` feature flag, making the enhanced
JSON
diffing component the default and only option. The now-unused legacy
diff
component and all related feature flag logic have been removed to
streamline the
codebase.
### 🚮 Removed
- **Components**
- `OldEventDiff` component was removed, along with its helper types and
constants.
- **Flag Logic**
- All conditional rendering based on the `improvedJsonDiff` flag was
removed.
- The `sort` prop from `EventDiff` was removed as it was only used by
the
legacy component.
- **Configuration**
- `improvedJsonDiff` flag definition was removed from `uiConfig.ts`,
`experimental.ts`, and `server-dev.ts`.
- **Tests**
- Mock configuration for `improvedJsonDiff` in tests was removed.
### 🛠 Kept
- **Components**
- `NewEventDiff` was renamed to `EventDiff` and is now the standard
implementation.
### 📝 Why
The `improvedJsonDiff` feature flag was marked as completed with its
outcome
being "kept". This cleanup finalizes the feature rollout by removing the
flag
and associated legacy code, simplifying the implementation and reducing
code
complexity.
---------
Co-authored-by: unleash-bot <194219037+unleash-bot[bot]@users.noreply.github.com>
Co-authored-by: Thomas Heartman <thomas@getunleash.io>
This PR cleans up the timestampsInChangeRequestTimeline flag. These
changes were automatically generated by AI and should be reviewed
carefully.
Fixes#10491
## 🧹 AI Flag Cleanup Summary
This PR removes the `timestampsInChangeRequestTimeline` feature flag.
The
feature is now permanently enabled.
⚠️ No conditional logic for this flag was found in the provided files.
The
changes are limited to removing flag definitions and configurations. The
actual
logic may reside in other parts of the codebase not included in this
operation.
### 🚮 Removed
- **Flag Definitions & Configuration**
- Removed `timestampsInChangeRequestTimeline` from `IFlagKey` type in
`src/lib/types/experimental.ts`.
- Removed `timestampsInChangeRequestTimeline` flag configuration from
`src/lib/types/experimental.ts`.
- Removed `timestampsInChangeRequestTimeline` from the `UiFlags`
interface in
`frontend/src/interfaces/uiConfig.ts`.
- Removed the flag from the experimental flags in `src/server-dev.ts`.
### 🛠 Kept
- **Feature Functionality**
- The behavior previously enabled by the
`timestampsInChangeRequestTimeline`
flag is now the default and only behavior.
### 📝 Why
The `timestampsInChangeRequestTimeline` feature flag was marked as
completed
with an intended outcome of "kept". This means the feature has been
rolled out
successfully and should be permanent. This cleanup removes the obsolete
flag and
its related configurations, simplifying the code and adhering to best
practices
for feature flag lifecycle management.
Co-authored-by: unleash-bot <194219037+unleash-bot[bot]@users.noreply.github.com>
## About the changes
This ignores Change Request event types when calculating the etag
because Change Request events don't change data.
They were being included when the change request event contained a
featureName. After this change, those should be excluded.
We will start separating traffic, when it comes from different origins.
Also will add it as primary key so merging will work correctly.
There is a problem with using normal down migration, is that if we split
data by origin, when down migrating and removing column, and re adding
the old migration, we will have conflicts and it will fail.
This means before we down migrate, we need to aggregate/sum the data and
only then we can reapply old schema.
## About the changes
This sets the minimum version for the new SDK names to the current
latest version. The versions with the new SDK name will be newer, but
this will set the baseline for the future.
https://linear.app/unleash/issue/2-3738/clear-unknown-flags-every-24h-instead-of-every-7d
Clears unknown flags every 24h instead of every 7d.
This ensures the list stays more relevant by removing stale entries
sooner, allowing users to focus on actively reported unknown flags.
Also includes small improvements, including a new paragraph on the
unknown flags page that better explains the concept of unknown flag
reports.
## About the changes
Previous PR: https://github.com/Unleash/unleash/pull/10439 introduced a
bug not allowing to update the strategy name
This PR modifies a test to also validate the change of strategy and
fixes the problem
## About the changes
When stickiness was set to empty or undefined while updating a strategy
via API the stickiness would be lost.
This adds a validation step after creating a strategy, that updating
with the same data used to create the strategy yields the same result.
The main change was lifting the default logic from the store layer to
the service layer and adapting tests accordingly
## About the changes
Follow up on https://github.com/Unleash/unleash/pull/10430 this PR
adapts documentation.
---------
Co-authored-by: Melinda Fekete <melinda.fekete@getunleash.io>
## About the changes
Rebrand SDK tokens and SDK types to make it easier to onboard and use:
**Backend SDK Token**: Intended for server-side SDKs. It can be used to
access:
- The Client Features API (/api/client/features) for fetching all flag
configurations for local evaluation.
- The Frontend API (/api/frontend) for remote evaluation.
**Frontend SDK Token**: Intended for client-side/frontend SDKs. It is
restricted and can only be used to access:
- The Frontend API (/api/frontend) for remote evaluation.
---------
Co-authored-by: Nuno Góis <github@nunogois.com>
When querying invalid tokens we might catch them for a while to reduce
database load. Being able to identify the token can help understanding
what's going on or the client using that token
Log looks like:
```
[INFO] /services/api-token-service.ts - Token default:development.3ef3... rate limited until: Tue Jul 29 2025 09:53:47 GMT+0000 (Coordinated Universal Time)
```
When deleting stale sessions, we sort them by createdAt. If both
sessions are created with the same createdAt, there's a chance we get a
different sort order and we end up with the wrong order:
https://github.com/Unleash/unleash/actions/runs/16438565746/job/46453700977
I think adding 10ms between inserts should be enough (1ms should do,
but this gives me more confidence and doesn't hurt that much)
---------
Co-authored-by: Thomas Heartman <thomas@getunleash.io>
https://linear.app/unleash/issue/2-3696/report-unknown-flags-when-sent-to-the-bulk-metrics-endpoint
Unifies metrics sifting logic across both metrics endpoints:
- `/metrics`
- `/metrics/bulk`
This PR improves consistency between the `/metrics` and `/metrics/bulk`
endpoints by introducing a shared `siftMetrics` method, now used within
`registerBulkMetrics`. Both endpoints already call this method at the
end of their respective logic flows, ensuring that metrics are sifted in
the same way regardless of the path taken.
While the primary goal was to enable reporting of unknown flags via the
`/metrics/bulk` endpoint, this change also improves bulk processing by
consistently dropping invalid or unknown flags before insertion, just
like in the regular `/metrics` endpoint.
Fixes a bug in the instance store where insert and bulkUpsert would
overwrite existing properties if there was a row there already. Now
it'll ignore any properties that are undefined.
The implementation is lifted directly from
`src/lib/db/client-applications-store.ts` (line 107 atm).
Additionally, I've renamed the `insert` method to `upsert` to make it
clearer what it does (and because we already have `bulkUpsert`). The
method seems to only be used in tests, anyway. I do not anticipate any
changes to be required in enterprise (I've checked).
## Discussion points:
This implementation uses `delete` to remove properties from the object.
Why didn't I do it some other way? Two main reasons:
1. We've had this implementation for 4 years in the client applications
store. If there were serious issues with it, we'd probably know by know.
(Probably.)
2. The only way I can think of without deleting, would be to use
`Object.fromEntries` and `Object.toEntries` and either map or reduce.
That'll double the amount of property iterations we'll need to do.
So naively, this strikes me as being more efficient. If you know better
solutions, I will of course be happy to take them. If not, I'd like to
leave this as is and then change it if we see that it's causing issues.
Fixes a bug where `registerInstance` and
`register{Frontend|Backend}Client` would overwrite each other's data in
the instance service, leading to the bulk update being made with partial
data, often missing SDK version. There's a different issue in the actual
store that causes sdk version and type to be overwritten when it's
updated (because we don't use `setLastSeen` anymore), but I'll handle
that in a different PR.
This PR adds tests for the changes I've made. Additionally, I've made
these semi-related bonus changes:
- In registerInstance, don't expect a partial `IClientApp`. We used to
validate that it was actual a metrics object instead. Instead, update
the signature to expect the actual properties we need from the cilent
metrics schema and set a default for instanceId the way Joi did.
- In `metrics.ts`, use the `ClientMetricsSchema` type in the function
signature, so that the request body is correctly typed in the function
(instead of being `any`).
- Delete two unused properties from the`createApplicationSchema`. They
would get ignored and were never used as far as I can tell. (`appName`
is taken from the URL, and applications don't store `sdkVersion`
information).
- Add `sdkVersion` to `IClientApp` because it's used in instance
service.
I've been very confused about all the weird type shenanigans we do in
the instance service (expecting `IClientApp`, then validating with a
different Joi schema etc). I think this makes it a little bit better and
updates the bits I'm touching, but I'm happy to take input if you
disagree.
This type wasn't available in enterprise, so I'm adding it to serer-impl
to make it available.
I was a little unsure whether this would be an implementation detail
that we shouldn't expose in server-impl, but comparing it with the other
things we export (`applyGenericQueryParams`, `flattenPayload`,
`basePaginationParameters`), that seems to be fine. I'm guessing this
isn't the main public export? Or it is, and we just don't care 🤷
https://linear.app/unleash/issue/2-3695/allow-empty-flag-names-to-be-reported-in-bulk-metrics
Accepts metrics with empty flag names in the `/api/client/metrics/bulk`
endpoint.
When testing unknown flags through Edge, which uses the `/bulk`
endpoint, we noticed that there's a slight difference in validation
behavior compared to the regular metrics endpoint. While the regular
endpoint allows empty flag names, this one does not.
We can argue that we don't care about empty flag names in the first
place, which is true, but this inconsistency between the metric
endpoints can be confusing, and it also means that a single empty flag
name evaluation would break metrics being reported for that entire Edge
instance, for example.
This way we still accept it, just like we currently do if we point to
Unleash directly instead of going through Edge.
**Note**: We noticed that, due to the slightly different logic branch,
the bulk metrics endpoint does not report unknown flags. We'll take a
look at this at a later point.
This is primarily to facilitate reading and processing these events in
the payg cloud section of Unleash. We only emit these in one place, so I
added the types in there.
I found this method when running through the environment store that has
0 references. I also can't find any references to it in enterprise and
it's not in the interface. I think it's safe to remove.
## About the changes
Users could have been created in Unleash without a corresponding event
(a.k.a. audit log), due to a non transactional user insert
([fix](https://github.com/Unleash/unleash/pull/10327)). This could have
happened because of providing the wrong role id or some other causes
we're not aware of.
This amends the situation by inserting an event for each user that
exists in the instance (not deleted) and doesn't have it's corresponding
user-created event.
The event is inserted as already announced because this happened in the
past.
The event log will look like this (simulated the situation in local
dev):
```json
{
"id": 11,
"type": "user-created",
"createdBy": "unleash_system_user",
"createdAt": "2025-07-08T16:06:17.428Z",
"createdByUserId": null,
"data": {
"id": "6",
"email": "xyz@three.com"
},
"preData": null,
"tags": [],
"featureName": null,
"project": null,
"environment": null,
"label": "User created",
"summary": "**unleash_system_user** created user ****"
}
```
The main problem is we can't create the event in the past, so this will
have to do it
## About the changes
When inserting a user with an invalid role id, the user creation will
succeed but there will be no record in the audit log.
The API call returns a 400 misleading you to believe the user was not
created, but it actually was.
This makes the whole user creation transactional, so if something fails,
data will be in the right state.
## Testing
The e2e test was split in 2 scenarios, one with smtp and another one
without.
This test was added, and it was failing before adding the transaction,
because when fetching the users, the user was there, despite having
returned a 400 error in the API call:
80a2e65b6f/src/test/e2e/api/admin/user-admin.e2e.test.ts (L181-L204)
I noticed event search, as it is doing `ILIKE` search, is slow
sometimes. Lets get some statistics about it.
Meanwhile added timers for other interesting queries.
As the title says. This adds name and email of requester to CR approval
mails. This will hopefully have users complain to their coworkers rather
than Unleash if they get too many mails.
Simple 2 columns for event type and event id.
I thought about adding check for type, but decided to handle checking in
backend code.
Currently the types will be
1. transaction
2. change-request
And ID is ulid
This change adds the `crDiffView` flag to Unleash, potentially enabling
the new JSON diff tab in change request changes instead of the "view
json diff" hover functionality.
