✨ [FFL-2858] Feature Flags tab — catalog browsing (stacked PR 2 of 3)

[kellyw1806]

Motivation

Stacked on #4913 (OAuth). With the sign in functionality, this PR helps include the fetch for the total feature-flag catalog. Users are now able to browse their feature-flag catalog. It does not involve overriding flags as that is the next PR (#4912).

Stack (review bottom-up)

	PR	Base	What it adds
1 of 3	#4913 · FFL-2597	main	OAuth sign-in
2 of 3	#4916 (this) · FFL-2858	ffl-2597	catalog browsing
3 of 3	#4912 · FFL-2596	ffl-2858	flag overrides

⚠️ Base is kelly.wang/ffl-2597, not main — merge #4913 first. This PR's diff is only the catalog layer.

Changes

• Fetches the catalog via the OAuth-capable GET /api/ui/ffe/feature-flags endpoint (paginated), transparently refreshing the token (getValidAccessToken, added here).
• Parses/maps flags + variants (defensive value parsing, dedupe-by-key), with search + type/tag filters and pagination.
• Expands the flags tab to render the catalog.

Demo

This is what the three PRs look like working together:

Screen.Recording.2026-07-24.at.5.14.31.PM.mov

Checklist

• Tested locally
• Tested on staging
• Added unit tests for this change (oauth.spec.ts — getValidAccessToken; flagCatalog.spec.ts).
• Added e2e/integration tests for this change.
• Updated documentation and/or relevant AGENTS.md file

[cit-pr-commenter-54b7da]

Bundles Sizes Evolution

📦 Bundle Name	Base Size	Local Size	𝚫	𝚫%	Status
Rum	180.54 KiB	180.54 KiB	0 B	0.00%	✅
Rum Profiler	8.43 KiB	8.43 KiB	0 B	0.00%	✅
Rum Recorder	21.12 KiB	21.12 KiB	0 B	0.00%	✅
Logs	57.05 KiB	57.05 KiB	0 B	0.00%	✅
Rum Salesforce	N/A	138.42 KiB	N/A	N/A	N/A
Rum Slim	138.41 KiB	138.41 KiB	0 B	0.00%	✅
Worker	22.96 KiB	22.96 KiB	0 B	0.00%	✅
Rum Shopify	N/A	200.11 KiB	N/A	N/A	N/A
Rum-shopify Profiler	N/A	8.43 KiB	N/A	N/A	N/A
Rum-shopify Recorder	N/A	3.72 KiB	N/A	N/A	N/A

[datadog-datadog-prod-us1]

🎉 All green!

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
• Patch Coverage: 76.56%
• Overall Coverage: 77.17% (+0.02%)

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 4dcadc8 | Docs | Datadog PR Page | Give us feedback!}

[BeltranBulbarellaDD]

@kellyw1806 In my opinion I would keep the stacked PR 2 and 3 in draft until the first one is approved. That way after changes are requested in the first one, this one remains clean for the reviewer.

[BeltranBulbarellaDD]

Let me know what you think! I think these comments will make the flags load almost instantly.

[BeltranBulbarellaDD]

Suggested change

	let offset = 0
	for (let page = 0; page < MAX_PAGES; page++) {
	const url = new URL(`https://${host}/api/ui/ffe/feature-flags`)
	url.searchParams.set('limit', String(PAGE_LIMIT))
	url.searchParams.set('offset', String(offset))
	const response = await fetch(url.toString(), {
	headers: {
	Authorization: `Bearer ${token}`,
	},
	})
	const url = new URL(`https://${host}/api/ui/ffe/feature-flags`)
	url.searchParams.set('page[limit]', String(request.pageSize))
	url.searchParams.set('page[offset]', String((request.page - 1) * request.pageSize))
	if (request.search) {
	url.searchParams.set('search', request.search)
	}
	for (const type of request.typeFilter) {
	url.searchParams.append('value_type', type)
	}
	for (const tag of request.tagFilter) {
	url.searchParams.append('tags', tag)
	}
	const response = await fetch(url.toString(), {
	headers: {
	Authorization: `Bearer ${token}`,
	},
	})

Instead of a for loop what do you think of this.
Because reading the API docs: "Pagination is always applied: the response includes meta.page (with total) and pagination links." Link.
So no need to do the loop to get the total we can request the 20 we will show and offset on page change. I think this way it loads faster and does not get unnecessary info.

[BeltranBulbarellaDD]

And then we can really simplify the useFlagCatalogView

[kellyw1806]

I think this might not work because it clashes with a couple of features the later PRs in this stack add, which both need the whole flag list loaded at once. For example, for overrides, you can override a flag's value locally, and we bump the ones you've overridden to the top so they're easy to find and the server can't do that (because it doesnt know which flags you overrode since they are stored locally in browser) A couple of the filters also break like the Tag and My Teams filter. So thinking maybe we keep the list loading client-side for now? Might also discuss this more with my team to see if they want to analyze this tradeoff

[BeltranBulbarellaDD]

Good point about locally overridden flags, but I don’t think caching every fetched flag in local storage solves it. Also I believe the endpoint supports search, type, regular-tag, and team-tag filtering server-side, so those filters shouldn’t require the complete catalog.
As for the following PRs in my opinion is better to tackle it when it comes. Else it's hard to keep track of both at the same time.

I'm thinking, what about having 2 parts?. The locally overriden flags in a set() above, when we open the extension we do a search for each to see if they match the server. And then below we have the rest. Where each time we do a pagination/search/filter we first check the results agains the set() so we don't show them twice.
This is because I am not confortable with fetching 2k feature flags on load each time.

[BeltranBulbarellaDD]

I think we could use a debounce here, like 3 secs so we don't run a search as soon as we write a character.