When the silence form is rendered we make a new alerts.json request to pull all instances of the alert being silenced and populate select boxes, so that user can silence not only currently displayed alerts, but all firing ones. When we do that only alerts displayed (matching filters) are colored properly because only those had color data in the global state, so some instances in those select boxes will be missing color data. To fix this merge global color data (from filtered alerts) with colors for alerts we collected, so when rendering happens we have color data for all instances.
v2 is an older implementation that doesn't require ES6, note from docs:
Note: If you need ES5 compatibility e.g. to use with older browsers, please use version 2 which has a slightly less feature-full API but is well-tested and about as fast as this implementation
Depending on exact value breaks when testing with a different Go version since implementation details might cause structhash to return a different hash. We don't depend on exact values in the UI, we only require that those values are unique to a unique set of labels and selected attributes, so that's what we should test rather than hardcoded values. This PR allows unsee to pass tests under Go 1.9beta2
If I would add a new 'go get foo' line in the build/deps.ok target it wouldn't install anything since the file we touch at the end already exist. Split all 'go get foo' lines into dedicated targets and make build/deps.ok depend on it. This way when you add a new build time dependency make will be able to do the magic and just install what's missing.
I made those change to add github.com/cespare/prettybench, it ended up adding little value so I dropped it, but Makefile refactor still seems like a good idea
Instead of grid update run a full update, after keeping tab in the background for too long some alert groups are kept in the DOM where they should be purged. Chrome does some really complex background tab throttling, interwebz states that after >=10s in the background a tab can only use 1% of the cpu. Future code might need to use Web Workers API, assuming other vendors will use it too (https://arstechnica.com/information-technology/2017/03/chrome-57-background-tab-suspension-download/). For now let's just reload alerts when user switches to a previously background tab after more than a single refresh cycle, this will ensure that there's no dead alerts presents since that can be confusing
Dynamic fingerprints made the code much slower, pprof shows they are responsible for ~70% of all cpu usage for any API call. To make it worse they are applied to all alerts, since dedup layer doesn't know which alerts will be filtered later, it operates on all of them. This PR will:
1. add benchmarks to so it's easier to track performance
2. Keep current methods for accessing fingerprints, but use precomputed static fields in those
3. Refactor Alert methods to use pointers, so we're not working on a copy
Benchmark timing went down from ~4000ns to 0.4ns for fingerprint calls and API response times from 1.3s (for my test sample) to 0.2s, which puts it back to the same level as before moving fingerprints to be dynamic. I still don't like this code much, it's all over the place, but I don't have a good idea how to better structure this, let's hope I'll be wiser in the future.
