1. This is a highly irreproducible error (in controlled setups) because it's happening somewhere along the programmatic chain and only happens when certain conditions are set in a production environment. Conditions that you can't record from the SDK since they are not made available via it's interface.
2. Although we record the environmental state at the point this error is thrown each and every time it happens in production in our analytics platform (
watchingthat.com) there is no clustering to point to any particular cause at this level so we believe it's somewhere in the configuration layer (ad tag etc) - and this correlates to the description provided by the IMA SDK as to its cause.
3. The SDK is throwing this error but does not provide any context around state at the point it throws the error. Specifically the ad tag that should be the cause of this is not made available. We have proven in our situation that this is nothing to do with the primary ad tag and is a redirect/wrapper tag.
4. The SDK Support team doesn't have any tooling/ability to further help troubleshoot this - we've been told that there are plans to improve the SDK to provide more of the required context/state at the point of the error being thrown but no time frames are given and things remain quite vague. The best suggestion they can offer is to run a Charles debug and pray you can replicate it - however see the first point that you need a very specific programmatic instance that makes it all but impossible to replicate.
At this point we've used the data we've collected ourselves to understand what it's not. We know it's not geographical, and we know it's not device specific. We also know it's not a content specific issue. And with our ability to track the timings of the introduction of this error and, over a time series, how it behaves over a 24 hr period we're tracking down changes at the ad server / demand stack to see if we can narrow down configuration changes as candidates.