We have a fairly complex dashboard the involves several pulldowns, tables, and charts. On the very top of the XML tree are several pulldowns that should be populated by URL query strings, using URL Loader.
At some point we noticed that not all of these are always populated. The first one always is, the second one usually is, and the third one, now, seems to never be properly populated. The behavior isn't completely deterministic, but in most cases it fails.
We investigated this a bit by removing parts of the report. We started by removing all custom behaviors, to no avail. Finally, I found that the existence of the FlashChart further down the XML causes this behavior upstream. If I replace the FlashChart with a simple results table the pulldowns are perfectly populated.
Another thing I noticed is that with the FlashChart, the pulldowns seem to go through the "Loading..." phase twice. With SimpleResultsTable, they go through it only once. Maybe this is somehow related?
Any help on this would be greatly appreciated.
Sounds like a fun bug. Send me the XML (nick at sideviewapps.com) and I'll take a look.
By any chance do you have more than one autoRun="True" in the view? Because that can certainly cause evil problems where the view ends up in an inconsistent state. Technically, you can envision the autoRun="True" as starting a push downstream from that point. If as you trace that push downstream, you run into another autoRun="true", that's very bad.
UPDATE ----------------
After working together to get a reproducible testcase against index=_internal data, we narrowed it down to a problem in Splunk's FlashChart module.
Basically onConnect calls onContextChange without checking whether the page is still loading. I vaguely remember tolerating this behavior, but I think the reason it was allowed to do this, has died with various other patches and circumventions applied from Sideview Utils to core splunk code. This call causes a lot of stale data to get cached, and while various paranoid code in the framework fixes most of it, the Pulldowns end up caught in a race condition.
Short version: I have added a patch to that module to Sideview Utils, and unless my QA finds some problems in the patch, it'll be up in Sideview Utils 1.3.1. If exploratory testing does find some problem with this patch, I'll fix it some other way. As always check release notes to see what exactly I fixed in any given Utils release.
Thanks very much for the bug report Yair, and for the back and forth to get a reproducible case.
Sounds like a fun bug. Send me the XML (nick at sideviewapps.com) and I'll take a look.
By any chance do you have more than one autoRun="True" in the view? Because that can certainly cause evil problems where the view ends up in an inconsistent state. Technically, you can envision the autoRun="True" as starting a push downstream from that point. If as you trace that push downstream, you run into another autoRun="true", that's very bad.
UPDATE ----------------
After working together to get a reproducible testcase against index=_internal data, we narrowed it down to a problem in Splunk's FlashChart module.
Basically onConnect calls onContextChange without checking whether the page is still loading. I vaguely remember tolerating this behavior, but I think the reason it was allowed to do this, has died with various other patches and circumventions applied from Sideview Utils to core splunk code. This call causes a lot of stale data to get cached, and while various paranoid code in the framework fixes most of it, the Pulldowns end up caught in a race condition.
Short version: I have added a patch to that module to Sideview Utils, and unless my QA finds some problems in the patch, it'll be up in Sideview Utils 1.3.1. If exploratory testing does find some problem with this patch, I'll fix it some other way. As always check release notes to see what exactly I fixed in any given Utils release.
Thanks very much for the bug report Yair, and for the back and forth to get a reproducible case.
Note: this patch to the FlashChart was posted as a part of Sideview Utils 1.3.1