Stream: restore noise cancellation and background blur, and put a size budget on the server function

[teetangh]

Parked from #1143, which was closed after failing to deploy 18 times out of 18. The work is preserved intact on parked/stream-call-filters at c1e574a2. Part of #1134.

This issue carries three things: what was built, why it was parked, and a standing risk that is larger than the feature itself.

The standing risk, first — because it outlives this feature

The operative limit is AWS Lambda's 250 MB unzipped package size (AWS quotas), which Netlify surfaces as Invalid AWS Lambda parameters used in this request on ___netlify-server-handler. It is not raisable. Vercel now offers functions up to 5 GB behind a flag; Netlify has no equivalent escape hatch.

The important correction is that the parked package was not 44 MB of lambda weight. Measured against this repo:

Path	Size	Reaches the server lambda
src/krispai/ (Krisp models)	33 MB	No. Referenced only through a runtime URL template — `unpkg.com/${packageName}@${packageVersion}/src/krispai/models` — with zero filesystem requires, so @vercel/nft has nothing to trace.
dist/cjs/index.js.map	5.5 MB	No. Next's serverIgnores includes **/*.map.
dist/cjs/index.js	5.4 MB	Yes. Statically imported from a "use client" component, so webpack inlines it into the SSR-layer server chunks.
dist/types/	44 KB	No, erased at build.

So roughly 5.4 MB tipped the deploy over. Which means the server function was already sitting near 245 MB, and this package was the last straw rather than the cause. The next dependency of any size will break the deploy again, and it will present exactly as this one did — every required check green, next build succeeding locally, and a failure only at the deploy stage.

That deserves its own attention regardless of whether noise cancellation is ever restored. node_modules here is about 1.5 GB, with @prisma at 164 MB and @sentry at 78 MB. The durable fix is a size budget on the handler, measured in CI, not a special case for one package.

The measurement to start from, which is also Netlify support's own recommended diagnostic:

netlify build
du -sh .netlify/functions-internal/___netlify-server-handler
du -sh .netlify/functions-internal/___netlify-server-handler/node_modules/* | sort -rh | head -30

Why the two fixes attempted during triage did not work

Both are recorded here because they are on the parked branch and both are no-ops. Anyone restoring that branch will otherwise assume they were merely misconfigured.

netlify.toml [functions] included_files = ["!…"] cannot shrink the Next.js server handler. The Netlify adapter writes a per-function config file containing includedFiles: ['**'] and nodeBundler: 'none', and zip-it-and-ship-it merges that file over your netlify.toml with a shallow spread (adapter source, zisi config). Because node_bundler ends up none, external_node_modules is inert too — Netlify documents it as applying only when the bundler is esbuild. The ! remedy is real, but it only appears in Netlify's legacy runtime v4 troubleshooting page, which carries a maintenance-support banner for Next.js 10–13.4.

outputFileTracingExcludes only prunes trace-delivered bytes. It cannot remove code webpack has already inlined into .next/server/chunks/*, and in the App Router external packages are bundled by default. Since the package is statically imported from a "use client" component, its bytes are inlined and no tracing exclude reaches them. Two further traps worth knowing if it is used elsewhere: the matcher runs with { contains: true }, so patterns match substrings and can silently delete unrelated paths (vercel/next.js#62331, still open); and Turbopack builds skip the mechanism entirely (vercel/next.js#77656, still open), which becomes relevant the moment this repo moves to Next 16 or passes --turbopack.

Moving the package to devDependencies would also be a placebo. Netlify sets no NODE_ENV by default, so devDependencies are installed, the import resolves, and webpack bundles it identically.

What would actually work

next/dynamic(..., { ssr: false }) around the noise-cancellation provider, called from inside a "use client" file. Next's SWC transform rewrites the loader to require.resolveWeak(...) on the server compilation, which resolves an id without creating a chunk dependency, so the module is not emitted into the SSR-layer output. This is the only approach among those considered that provably removes the 5.4 MB, and it fits the existing design, which already does not mount the provider by default.

Note that "use client" alone does not achieve this — client components are server-rendered by default in the App Router, which is precisely the trap that produced this bug.

What is already built, on parked/stream-call-filters

Restoring this is a rebase and a checkout, not a rewrite. The branch is based on an older dev and must be rebased first — much of its apparent diff is unrelated chat and script work that has since merged.

File	What it does
app/meetings/[id]/components/NoiseCancellationGate.tsx	Owns the Krisp provider. Deliberately mounted outside the dropdown, because Radix unmounts closed menu content and would tear the provider down.
app/meetings/[id]/components/CallFiltersProvider.tsx	Wraps both the lobby and the room, because the filter registers on call.camera and a provider unmounting between them would unregister it exactly as the person joins.
app/meetings/[id]/components/CallEffectsMenu.tsx, EffectRow.tsx	The in-call effects UI.
scripts/copy-stream-filter-assets.mjs	Copies the WASM and model files out of node_modules into public/ at postinstall, so they are served from our own origin.
next.config.mjs CSP changes	worker-src pinned rather than inherited, wasm-unsafe-eval and blob: added to script-src.

The self-hosting is worth keeping exactly as it is. public/ is copied to Netlify's static output, not into the lambda, so it costs zero function bytes — and it matches Stream's own documented mechanism, which otherwise fetches models from unpkg.com at runtime from inside a live consultation. That would put a third party on the call path and require opening connect-src to them.

One review comment from #1143 is unaddressed and belongs to this work: dropdown triggers in CallEffectsMenu.tsx omit an explicit type attribute and rely on Radix forwarding it.

The product question

Noise cancellation via Krisp is a paid Stream add-on billed per participant-minute. That is a recurring cost on a pre-MVP product for a feature nobody has asked for, and the billing shape is awkward on its own terms: Stream meters the whole call, but the feature is toggled by a single participant, so it is unclear who should pay when a consultee switches it on. Charging for it would need per-call metering, reconciliation against Stream's invoice, and a dispute path — disproportionate machinery for an audio nicety.

I was unable to verify Stream's current published pricing for this add-on. The research pass that was to confirm the exact unit and whether it bills the whole call or only the enabling participant did not complete. That should be confirmed before any pricing decision, and it is the crux of the deferral rather than a detail.

Background blur is a separate, cheaper case

@stream-io/video-filters-web arrives as a transitive dependency of @stream-io/video-react-sdk, so it is installed on dev regardless and dev deploys fine. Restoring blur adds no package that is not already present. It is not paid. It is a much better candidate for near-term work than noise cancellation, subject to the same ssr: false treatment and the same size budget.

Suggested order

1. Measure the server function and establish a size budget checked in CI. This is worth doing whether or not either feature returns, because the next dependency will otherwise reproduce this failure.
2. Restore background blur with next/dynamic(..., { ssr: false }), since it costs no new dependency.
3. Revisit noise cancellation post-MVP, once Stream's billing model is confirmed and there is a pricing structure that can absorb it.

[teetangh]

The billing research, which changes what this issue is waiting on

The issue body above says Stream's published pricing for this add-on could not be confirmed and flags it as the crux of the deferral. It has now been researched, and the answer is more useful than expected.

The rate is $0.30 per 1,000 participant minutes (getstream.io/video/pricing). For scale, that is the same rate as an audio-only participant minute and one fifth of the $1.50 that HD video costs. A 60-minute two-person consultation with the filter on throughout costs $0.036 under the most expensive reading.

So the money was never the problem. At our volume the absolute cost is trivial. The real objection is narrower and still stands: we cannot currently predict or attribute it.

The question Stream does not answer

Noise cancellation is toggled by a single participant but billed in participant minutes, and no published page states whether those minutes are counted for every participant on the call or only for the one who enabled it. Four pages were checked and none address it — the pricing page, the pricing guide, and the React and Android noise-cancellation guides.

There is strong circumstantial evidence for the cheaper reading, and it comes from the SDK rather than the docs. In @stream-io/video-client the client subscribes to the filter's own change event and calls notifyNoiseCancellationStarting() and notifyNoiseCancellationStopped(), both thin wrappers over sfuClient.startNoiseCancellation() / stopNoiseCancellation(), which run on that one participant's SFU connection. A metering signal sent per participant, bracketing the interval that participant had the filter on, is hard to reconcile with whole-call billing.

That is an inference from SDK behaviour, not a documented guarantee. It is one email to Stream support and it settles the question entirely.

The hazard that matters more than the rate

The live default call type has settings.audio.noise_cancellation.mode set to "auto-on" — re-verified directly against the live app. In that mode the client enables the filter by itself the moment the call reaches JOINED, provided a NoiseCancellation instance has been registered. Registering the instance and switching on billing are therefore the same act. Mounting NoiseCancellationProvider unconditionally would have added a per-minute charge to every consultation on the platform on the day it shipped.

The parked implementation already defuses this correctly, and it is worth stating so nobody "simplifies" it later: the provider is the switch. NoiseCancellationProvider is rendered only when the user has turned the feature on, so "off" means unmounted — nothing initialised, no Krisp model fetched, nothing billed.

An earlier comment on #1134 claimed this call type was not set to auto-on. That was wrong — it read settings.noise_cancellation rather than settings.audio.noise_cancellation — and has been retracted there.

What this changes about the ordering

Before shipping, change the server-side call-type setting from auto-on to "available". That way the filter is enabled only by explicit client action rather than automatically on join, and a future mistake in the provider's mounting logic cannot silently start billing.

The deferral now rests on two things rather than three: the Lambda size problem described above, and one unanswered support question about billing scope. Neither is hard to close. Neither is worth closing before there are paying users.

Related: #1160 assesses the rest of Stream's paid surface, and notes that most of it — transcription, closed captions, HLS, RTMP, frame/individual/raw recording — currently sits at mode: "available" on our call type rather than disabled, meaning it is startable today by anyone holding the capability.