1
0
mirror of https://github.com/Unleash/unleash.git synced 2025-02-04 00:18:01 +01:00
unleash.unleash/src/lib
Thomas Heartman a115f89183
feat: include segment usage in CRs when showing usage in projects and flags (#5327)
This PR updates the segment usage counting to also include segment usage
in pending change requests.

The changes include:
- Updating the schema to explicitly call out that change request usage
is included.
- Adding two tests to verify the new features
- Writing an alternate query to count this data

Specifically, it'll update the part of the UI that tells you how many
places a segment is used:


![image](https://github.com/Unleash/unleash/assets/17786332/a77cf932-d735-4a13-ae43-a2840f7106cb)

## Implementation

Implementing this was a little tricky. Previously, we'd just count
distinct instances of feature names and project names on the
feature_strategy table. However, to merge this with change request data,
we can't just count existing usage and change request usage separately,
because that could cause duplicates.

Instead of turning this into a complex DB query, I've broken it up into
a few separate queries and done the merging in JS. I think that's more
readable and it was easier to reason about.

Here's the breakdown:
1. Get the list of pending change requests. We need their IDs and their
project.
2. Get the list of updateStrategy and addStrategy events that have
segment data.
3. Take the result from step 2 and turn it into a dictionary of segment
id to usage data.
4. Query the feature_strategy_segment and feature_strategies table, to
get existing segment usage data
5. Fold that data into the change request data.
6. Perform the preexisting segment query (without counting logic) to get
other segment data
7. Enrich the results of the query from step 2 with usage data.

## Discussion points

I feel like this could be done in a nicer way, so any ideas on how to
achieve that (whether that's as a db query or just breaking up the code
differently) is very welcome.

Second, using multiple queries obviously yields more overhead than just
a single one. However, I do not think this is in the hot path, so I
don't consider performance to be critical here, but I'm open to hearing
opposing thoughts on this of course.
2023-11-14 08:49:32 +01:00
..
__snapshots__ chore: add detect segment usage in CRs flag (#5302) 2023-11-08 15:06:01 +01:00
addons feat: remove feature flag for datadog json template (#5105) 2023-10-26 09:09:26 +02:00
db feat: include segment usage in CRs when showing usage in projects and flags (#5327) 2023-11-14 08:49:32 +01:00
domain/project-health
error fix: take into account project segments permission (#5304) 2023-11-09 09:37:47 +00:00
features feat: sort favorites on the backend (#5326) 2023-11-14 09:22:35 +02:00
middleware fix: segment project fetch when global (#5311) 2023-11-09 13:27:12 +00:00
openapi feat: include segment usage in CRs when showing usage in projects and flags (#5327) 2023-11-14 08:49:32 +01:00
proxy chore: expose types so we can use them properly (#5251) 2023-11-03 12:00:24 +01:00
routes chore: import IUser instead of User for auth (#5269) 2023-11-06 10:46:59 +01:00
schema
segments feat: API prevents you from deleting segments in crs (#5308) 2023-11-09 12:09:39 +01:00
services chore: log unerlying DB error in set user root role (#5324) 2023-11-13 12:16:01 +01:00
types Fix/scheduled request UI (#5318) 2023-11-10 11:22:03 +02:00
util
app.test.ts
app.ts chore: expose custom-handler-auth type (#5287) 2023-11-07 10:37:09 +01:00
create-config.test.ts
create-config.ts feat: make all internal rate limits configurable (#5095) 2023-10-26 09:20:29 +02:00
default-custom-auth-deny-all.ts chore: expose custom-handler-auth type (#5287) 2023-11-07 10:37:09 +01:00
internals.ts
logger.test.ts
logger.ts
metric-events.ts
metrics.test.ts
metrics.ts feat: make all internal rate limits configurable (#5095) 2023-10-26 09:20:29 +02:00
server-impl.test.ts
server-impl.ts chore: expose custom-handler-auth type (#5287) 2023-11-07 10:37:09 +01:00