fix MPP-4559: feat(masks): make free mask limit configurable per environment by groovecoder · Pull Request #6280 · mozilla/fx-private-relay

groovecoder · 2026-02-11T16:18:39Z

This PR fixes MPP-4559.

How to test:

Checkout this branch
Set your MAX_NUM_FREE_ALIASES env var to a new number (e.g., 10)
cd frontend && npm run build
cd .. && python manage.py collectstatic
python manage.py runserver
Go to the dashboard as a free user and create the new max number of free aliases
- When you create 1 less than the max, you should see the bottom-right upgrade notification
- When you create the max number, you should see the top "hero" upgrade banner
(Optional) Set your MAX_NUM_FREE_ALIASES env var to a new higher number (e.g., 15)
Repeat steps 3-6 to check that the code works as expected with the new higher env var value

~~l10n changes have been submitted to the l10n repository, if any.~~
I've added or updated a unit test to test for potential regressions of this bug.
~~I've added or updated relevant docs in the docs/ directory.~~
~~All UI revisions follow the coding standards, and use Protocol / Nebula colors where applicable (see /frontend/src/styles/colors.scss).~~
Commits in this PR are minimal and have descriptive commit messages.

jwhitlock

This may go beyond the scope of MPP-4559, which only covered updating the mask limit on the API side. This looks more like it is getting into the Relay Dashboard work, which would include e2e tests in MPP-4563.

Since this is mostly frontend code, I'm commenting rather than approving or requesting changes

api/views/privaterelay.py

jwhitlock · 2026-02-11T22:20:24Z

frontend/src/config.ts

  emailSizeLimitNumber: 10,
  emailSizeLimitUnit: "MB",
-  maxFreeAliases: 5,
+  maxFreeAliases: 50,


I'm concerned this could ship the new mask limit when it goes to production. Is product OK with that, or did they want to coordinate across clients (Firefox integration, add-on)

this work covers MPP-4570

I introduced a new waffle flag increased_free_mask_limit to control whether the app will use the MAX or INCREASED_MAX value.

vpremamozilla · 2026-02-11T22:36:37Z

frontend/__mocks__/api/mockData.ts

+  // Note: Set to 5 for test performance. Production default is 50 (see runtimeData-default.ts),
+  // but tests use 5 to avoid creating 49 aliases to trigger limit-related UI.
+  MAX_NUM_FREE_ALIASES: 5,
 };


this work covers MPP-4570

vpremamozilla · 2026-02-11T22:49:24Z

ran unit test suite, looks like this PR also covers MPP-4571

vpremamozilla · 2026-02-11T22:53:03Z

frontend/src/components/dashboard/CornerNotification.tsx

+  const maxFreeAliases = runtimeData.MAX_NUM_FREE_ALIASES;
+  const showAtMaskCount = maxFreeAliases - 1;
+
  if (


this work covers MPP-4572

only question i have for product/UX - do we want this to pop up maybe for the 25 mask mark? or is waiting until 49 still an appropriate use for this component?

vpremamozilla · 2026-02-11T23:00:26Z

Overall this looks good to me, it does cover several of the frontend tickets relating to the mask limit expansion initiative - MPP-4570, MPP-4571 and MPP-4572

only thing i would double check (and maybe this is something youve already considered looking at the PR)
what i observed is that there are TWO separate config systems:

Frontend config (getRuntimeConfig() from config.ts) – contains maxFreeAliases
Backend runtime data (from /runtime_data API) – contains feature flags, product IDs, etc., but NO mask limit

it looks like if its not set in Django, that you are using the setting in the frontend config.ts file, if thats intentional i'd say it looks good to me (and makes the most use of the backend api value)

joeherm · 2026-02-12T16:41:47Z

This looks good, but I'm a bit worried about this line in the add-on being hardcoded:
https://github.com/mozilla/fx-private-relay-add-on/blob/4e86761189aef430492c4f2d5b21bc660052ae87/src/js/background/background.js#L4

It would be good to get a timeline + sequence of the rollout strategy that takes into account the different Relay clients. If we change the frontend default from 50 to 5 as suggested by @jwhitlock and @vpremamozilla above, I'd still probably feel comfortable merging this down. We could then do follow on PRs for FF/add-on, and the webservices-infra ConfigMap updates.

…ronment Backend exposes `MAX_NUM_FREE_ALIASES` via `runtime_data` endpoint. Frontend fetches the value and falls back to hardcoded 5. Components use runtime data instead of static config. Waffle flag "increased_free_mask_limit" controls which limit applies. Two environment variables set the values: - MAX_NUM_FREE_ALIASES (default: 5) - INCREASED_MAX_NUM_FREE_ALIASES (defaul: 50) Dev and stage can now set higher limits without rebuilding frontend. Single build works across all environments. Each environment can run with MAX or INCREASED_MAX via waffle flag.

groovecoder · 2026-02-12T22:13:44Z

I introduced a new waffle flag increased_free_mask_limit to control whether the app will use the MAX or INCREASED_MAX value.

This way, we can merge this code, and set the env var and waffle flag in dev & stage servers:

Dev
- INCREASED_MAX_NUM_FREE_ALIASES=50
- increased_free_mask_limit flag = everyone
Stage
- INCREASED_MAX_NUM_FREE_ALIASES=50
- increased_free_mask_limit flag = everyone
Prod
- INCREASED_MAX_NUM_FREE_ALIASES=50
- increased_free_mask_limit flag = individual accounts & QA

For the add-on, here's a first draft PR to make it also pull from the runtime_data endpoint rather than hard-code: mozilla/fx-private-relay-add-on#563

joeherm

With the waffle-flag and add-on work this LGTM.

groovecoder · 2026-02-13T17:04:52Z

@vpremamozilla, re:

only thing i would double check (and maybe this is something youve already considered looking at the PR)
what i observed is that there are TWO separate config systems:
Frontend config (getRuntimeConfig() from config.ts) – contains maxFreeAliases
Backend runtime data (from /runtime_data API) – contains feature flags, product IDs, etc., but NO mask limit
it looks like if its not set in Django, that you are using the setting in the frontend config.ts file, if thats intentional i'd say it looks good to me (and makes the most use of the backend api value)

Yes that's intentional. Your comment made me realize that getRuntimeConfig and runtimeData are two separate things and their conflicting names make things confusing. So I filed https://mozilla-hub.atlassian.net/browse/MPP-4578 and attached an implementation plan to clean that up in aother PR.

groovecoder requested a review from vpremamozilla February 11, 2026 17:09

groovecoder force-pushed the update-mask-limit-mpp-4559 branch from 640e18f to f4430d2 Compare February 11, 2026 17:46

groovecoder changed the title ~~feat(masks): make free mask limit configurable per environment~~ fix MPP-4559: feat(masks): make free mask limit configurable per environment Feb 11, 2026

jwhitlock reviewed Feb 11, 2026

View reviewed changes

vpremamozilla reviewed Feb 11, 2026

View reviewed changes

groovecoder force-pushed the update-mask-limit-mpp-4559 branch from f4430d2 to 0b73e52 Compare February 12, 2026 21:16

groovecoder force-pushed the update-mask-limit-mpp-4559 branch from 0b73e52 to 021e257 Compare February 12, 2026 21:20

joeherm approved these changes Feb 13, 2026

View reviewed changes

vpremamozilla approved these changes Feb 13, 2026

View reviewed changes

Conversation

groovecoder commented Feb 11, 2026

Uh oh!

jwhitlock left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

jwhitlock Feb 11, 2026

Choose a reason for hiding this comment

Uh oh!

vpremamozilla Feb 11, 2026

Choose a reason for hiding this comment

Uh oh!

vpremamozilla Feb 11, 2026

Choose a reason for hiding this comment

Uh oh!

groovecoder Feb 12, 2026

Choose a reason for hiding this comment

Uh oh!

vpremamozilla Feb 11, 2026

Choose a reason for hiding this comment

Uh oh!

vpremamozilla commented Feb 11, 2026 • edited by atlassian bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vpremamozilla Feb 11, 2026

Choose a reason for hiding this comment

Uh oh!

vpremamozilla commented Feb 11, 2026 • edited by atlassian bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

joeherm commented Feb 12, 2026

Uh oh!

groovecoder commented Feb 12, 2026

Uh oh!

joeherm left a comment

Choose a reason for hiding this comment

Uh oh!

groovecoder commented Feb 13, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

vpremamozilla commented Feb 11, 2026 •

edited by atlassian bot

Loading

vpremamozilla commented Feb 11, 2026 •

edited by atlassian bot

Loading