✨ Feature Flags tab — all Datadog sites, with overrides scoped per site

[kellyw1806]

Adds the remaining Datadog sites to the Flags tab, and fixes a bug that expansion exposed.

---

The bug

The wrapper stores flag overrides in the inspected page's localStorage under a single key with no Datadog site in it. localStorage is scoped per browser origin, not per Datadog site — so staging and US1 share one bucket on the same page.

Set an override on staging → reconnect to US1 → it's still there and still applying. If the same flag key exists in both environments with the same type (normal for a flag promoted through environments), nothing looks wrong at all: the row renders as an ordinary US1 override, and the page quietly behaves according to a value you set in staging.

The fix

The wrapper can't be changed, so the extension keeps its own per-site stores and projects the connected site's into the key the wrapper reads:

dd.dd_flag.overrides.datad0g.com     ← staging's overrides
dd.dd_flag.overrides.datadoghq.com   ← US1's overrides
dd.dd_flag.overrides                 ← projection of the site you're connected to (what the wrapper reads)

Staging's copy is parked where the wrapper can't see it. Switch to US1, reload, and the page uses US1's real values; switch back, reload, and your staging override returns. Nothing is deleted, and the wrapper needs no change.

Three properties worth calling out, because they're where the design decisions live:

Signing in stays inert. The projection is compared before it's written and skipped when nothing would change. Reconnect to the site you used last time and nothing is written and nothing is prompted — a reload is only ever demanded when the page genuinely is running another site's values.

Pre-scoping overrides are dropped, not migrated. The site store is the only source, so anything left in the wrapper's key by an older build is cleared on first connect. The tab shipped days ago, so there's no override history worth carrying forward — and skipping the migration removes the adoption gate along with everything guarding it.

A failed projection is surfaced, not assumed. If the write fails, the page may still be applying another site's overrides while the panel shows this site's. That now raises an error instead of passing silently.

Also in this PR

Site picker — adds US3, US5, EU1, AP1, AP2 (previously US1 + staging only). FED/GovCloud stays out: separate deployment, client isn't registered there.

Clear all before signing in. The signed-out notice warned that overrides were active but gave no way to act on them. It now has its own Clear all with a confirm step, surfaced failures, and a reload prompt (the page keeps applying them until it rebuilds its provider).

Signed out there's no site to scope to, so the notice reports every stored override and Clear all wipes all of them. Reporting only the wrapper's key would hide an override the page is still applying: a switch repoints that key before the reload that picks it up, so switching and then disconnecting without reloading would leave the notice empty while the old site's override was still in effect. Clearing only that key has the mirror problem — the rest would come back on reconnect, as if the button hadn't worked. The confirmation says it covers every site.

Row warnings, split by severity. The cross-environment warning is gone — an override in a site's store is that site's by construction. What remains:

Signal	Treatment
Stored type disagrees with the flag	Red row — the wrapper rejects it at resolve time, so it genuinely won't apply
No active flag holds the key	Dimmed note — archived or deleted since the override was set; the override still resolves fine

Known limits

• Overrides written outside the extension. The site store is the only source, so anything written straight to the wrapper's key — by hand in the console, or by an older build — is overwritten on the next sync. Documented on syncSiteOverrides.
• Switching sites while a write is in flight. The provider remounts on a site change, so a write dispatched just before the switch can land after the new site's projection and restore the old site's overrides until the next sync. Each eval is atomic, so the stores themselves stay consistent. Accepted and documented, alongside the existing navigation-race note in that file.
• The manual override form can still create a type mismatch. It validates against the currently loaded catalog page only, so a flag on another page can be overridden with the wrong type. Pre-existing; now the main way to produce the red row. The proper fix is validating against an exact-key lookup, which makes Apply asynchronous — left for follow-up.

Testing

• yarn typecheck, yarn lint, yarn format clean
• 94 unit tests passing. The storage tests run the real eval code against a real localStorage, so they exercise the projection and clear paths rather than mocks.

Verified manually, both directions. Worth running both if you're reviewing this — the first shows the leak is closed, the second shows nothing was destroyed closing it. Use a flag with a visible effect (dark mode works well) that exists in both environments.

Leak is closed:

1. Connect to Staging, override the flag on, reload → page picks it up.
2. Disconnect → the signed-out notice reports the stored override and offers to clear it.
3. Connect to US1 → the reload banner appears.
4. Reload → the staging override is gone and the page uses US1's real value.

Nothing was destroyed:

5. Switch back to Staging → reload banner again.
6. Reload → the staging override is back and applying.

Step 6 is the one that matters. Steps 1–4 alone can't tell a parked override from a deleted one; only the round trip shows the store survived the switch.

[BeltranBulbarellaDD]

Small nits. But let's see if it would be nicer to just filter by site in the local storage. It's not the full solution but I think would simplify a little the code here. So we fetch only the ones on the logged in site for example.
All the rest looks good! I'll take a closer look after the changes.

[cit-pr-commenter-54b7da]

Bundles Sizes Evolution

📦 Bundle Name	Base Size	Local Size	𝚫	𝚫%	Status
Rum	181.27 KiB	181.27 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.50 KiB	57.50 KiB	0 B	0.00%	✅
Rum Salesforce	N/A	139.22 KiB	N/A	N/A	N/A
Rum Slim	139.21 KiB	139.21 KiB	0 B	0.00%	✅
Worker	22.96 KiB	22.96 KiB	0 B	0.00%	✅
Rum Shopify	N/A	200.99 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-2]

🎉 All green!

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
• Patch Coverage: 64.41%
• Overall Coverage: 77.14% (-0.07%)

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 8bdf3fb | Docs | View more details | Give us feedback!}

[BeltranBulbarellaDD]

Works great!

[BeltranBulbarellaDD]

LGTM!