To properly debug this, make sure your control rig is checked into your revision control. From there do a divide and conquer approach to delete half the controls to see if the error goes away and keep dividing until the error goes away and look at the other half of the deleted controls. You would leverage revert on revision control to revert back to the original state after isolating the error.
In my case there was a channel name that was internally duplicated with script name that was causing the error. Deleting the erroroneous channel and recreating it fixed the issue. Output log won’t show it. You have to consistently add the control rig to a fresh sequencer to check the error. Adding the control rig as a possessible won’t show up. It only shows up when created as a binding on a possessible, so the quickest way to test is to drag the control rig from content browser on to the viewport.
It’s inherently caused by a weird design setup where a channel has two internal variables. The channel name is the visible name while the script name is the unique id on the control rig for the channel. Although it may display one thing, what’s internally saved maybe something different so you may have an ok looking channel that’s actually internally corrupt. Identifying, deleting and recreating it will fix the issue.
An example of legacy tech debt not cleared from Manny/MetaHumans is head_stretch under head_ik_ctrl. This is not used anywhere in the control rig but still exists as an orphaned channel.
One example of a used one that has a different naming is local under head_ctrl. The script name is actually head_local.
In the blueprint, it is only referred to as head_local.
When you duplicate these channels internally it will try to make the script name unique. If done incorrectly it could cause corrupt internal data.