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.
- checkbox to select 'rate' vs 'increase' - always available for now,
but does nothing for gauge. I can improve it later on
- better preview - it will show resolved query underneath
- cleaner error handling that doesn't overflow widgets
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)
Updates a few remaining places where we check constraint operators with
the new constraint operator checks. Additionally, because there was only
one remaining place where we used the `oneOf` function, I replaced it
with a normal `includes` check and deleted the `oneOf` util. From what I
can tell, there's no need to have that utility function; it doesn't
provide much benefit over using the language built-ins 🤷🏼
Doesn't clear the value from the constraint input value popover if you
close it and then re-open. In other words, if you accidentally click
out, you don't lose your progress. Instead, the popover will open again,
with the value you had when you closed it highlighted (so that it's easy
to type over if you want to):
<img width="452" alt="image"
src="https://github.com/user-attachments/assets/d86aa00e-4956-40a8-8fea-e75be5d5425b"
/>
The reason I'm changing this now is because I noticed that the error
wasn't cleared correctly when the popover was closed. If we do it this
way instead, then that makes sense, because you can still see the value.
This is also how the single-value popover has worked forever.
From some quick testing, the single value popover still works as
expected:
<img width="562" alt="image"
src="https://github.com/user-attachments/assets/9041a922-b055-4310-ab60-93ad219981a4"
/>
As a side note: I'm adding a comment to anyone coming after as to why
focus handling on escape doesn't work correctly on the single value
button. I was about to go down a rabbit hole on that before I read my
own comment on the previous PR. So I thought I'd put that here too.
Makes it so that the constraint value input gives you an error if you
try to add one or more values that **all** exist in the set of values
already. E.g. if you have `a` and `b`, and try to add `a`, it'll tell
you that "`a` has already been added". Likewise, if you try to add
`a,b`, it'll tell you that all these values already exist. However, if
at least one of the values does not exist, then it will allow you to
submit the values (we already do deduplication before storing anyway).
The background for this is that a user was confused thinking that just
one specific value didn't get added to their constraints. As it turns
out, they'd already added the value previously, so when it didn't show
up at the end of the list, they thought it didn't work at all.
<img width="863" alt="image"
src="https://github.com/user-attachments/assets/12195e0a-04bc-4b41-bd44-432120c768a6"
/>
<img width="816" alt="image"
src="https://github.com/user-attachments/assets/433a64d7-aec0-482d-8544-574656c266ce"
/>
---------
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
This PR updates how we show old/new strategy/segment names in change
requests, and also removes the name of the strategy type from the
change.
For the old/new names: instead of showing them stacked vertically, we
show them side by side (old name first, then new name).
Compare before:
<img width="967" alt="image"
src="https://github.com/user-attachments/assets/d3e36f49-4abc-4cd4-8ba9-752515740185"
/>
with after:
<img width="974" alt="image"
src="https://github.com/user-attachments/assets/d0f85264-b055-4c44-b985-f992f09d8dab"
/>
Only affects the new components (legacy CR view is untouched). If we get
negative feedback while rolling it out because the strat type name is
missing, we can always add it back.
The max width is set to `max(40vw, 1000px)`, so that if you're on a very
wide window, then it'll take up at most 40% of the horizontal space.
Once your window is smaller than 2500px, however, the sidebar will stop
shrinking and stay at 1000px (or as close to that as the window allows).
It'll keep shrinking with the window size.
This came up because in certain cases, such as if you have a release
template with a long description, the modal would just keep growing
until it took up 98% of the window width.
I have not set a min width for now. I don't think there is any need for
it, but if we find there is, we can add it back later.
Before:
After:
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.
