Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Don't kill an entire dashboard because of one bad request #11337
Summary: Previously if a visualization caused a request error to be thrown, the entire dashboard would fail to load. We changed that so now the rest of the visualizations will continue to load successfully, helping you narrow down which visualizations the errors are coming from.
Note: I will clean the code up if this way forward is approved (and add a hefty amount of comments) but waiting for feedback before spending the time.
It filters out failing requests, and considered them "aborted". I briefly investigated marking them as failures, which might work too, but it doesn't seem to make a difference.
The logic is extremely convoluted and I'm not confident this doesn't raise issues in other situations. I started working on some clean up but it went farther and farther and decided to extricate myself. I could continue back down that path, but it's time consuming.
So @spalger I'd like to get your opinion on this and what you think the best way forward is. It looks like our courier was never meant to handle partial failures. Making this more explicit would require some refactoring and I'm not sure the time investment is worth it.
But this implementation does solve the issue, and dashboards will now show all visualizations except the failing ones which are blank. They should probably show the error inside the visualization, but because it's a top level notify error, this isn't clear.
The fix, while a bit hacky, could prove really helpful in debugging user issues because it helps a user narrow down the faulty visualizations. The field error is pretty common and takes some time to figure out which field is killing the visualization which is killing the entire dashboard.
I've seen this flaky failure before:
jenkins, test this