Renaming a user parameter on a Niagara System breaks every Blueprint call site and every placed component override, and it does it without a warning anywhere.
The setters are keyed by name, so there’s nothing to fail against. In UE 5.8, FNiagaraParameterStore::SetParameterValue (NiagaraParameterStore.h, the template at line 562) takes the bAdd branch at 582 when the name is not already in the store: it calls AddParameter, memcpys the value into the new entry, and returns true. The System does not expose that parameter, so nothing ever reads it. On the component side UNiagaraComponent::SetVariableFloat (NiagaraComponent.cpp:2864) returns void, so a defensive caller cannot check the result even if it wants to. Nothing is logged on that path.
What that looks like in a project is an effect that simply stops responding after a rename, with no error to search for and no red node in the graph. The usual way it gets found is someone noticing months later that a value never mattered.
The plugin indexes every exposed user parameter on every Niagara System in the project against every SetNiagaraVariable call site, including overrides set on components placed in levels, and reports the ones that no longer resolve to a parameter the System exposes.
Disclosure, since it should be up front: this plugin is written and illustrated by AI, and that is stated on both listings.
Fab: Niagara User Parameter Surgeon - Find Every Call Site a Rename Silently Broke | Fab
itch: Niagara User Parameter Surgeon for Unreal Engine 5 by CSAF — Core Systems Asset Factory