Handle Error stored in redux trace.traces

[tiffon]

Fix #166.

HTTP responses >= 400 (e.g. 404s) cause an Error to be added to the redux store in trace.traces[traceID]. This PR prevents the search page from treating them as a normal trace.

[tiffon]

@simonrobb can you look this over when you get the chance?

[codecov]

Codecov Report

Merging #195 into master will decrease coverage by 0.03%.
The diff coverage is 75%.

@@            Coverage Diff             @@
##           master     #195      +/-   ##
==========================================
- Coverage    91.5%   91.46%   -0.04%     
==========================================
  Files          95       95              
  Lines        2130     2133       +3     
  Branches      434      435       +1     
==========================================
+ Hits         1949     1951       +2     
- Misses        160      161       +1     
  Partials       21       21

Impacted Files	Coverage Δ
src/model/search.js	97.29% <75%> (-2.71%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2e6d1a4...bafe9a6. Read the comment docs.

[yurishkuro]

not sure I am following the typing here: _traces is an array of Trace objects, how could getTraceSummary function be called with an Error object?

[tiffon]

It's an inefficiency or irregularity in the state of static typing in the repo. Some files have flow-types and some do not.

The type here is really (Trace | Error)[].

[yurishkuro]

so maybe the fix should be (using Scala-ish notation)

_traces.filterNot(_ instanceof Error).map(getTraceSummary);

?

or even do the filtering somewhere upstream, instead of propagating the mixed type deeper.

[simonrobb]

Agreed. At the least, if it's possible for there to be Error objects present, the parameter type should be annotated like you described, getTraceSummaries(_traces: (Trace | Error)[]): TraceSummaries.

[tiffon]

@yurishkuro Great point. I will filter then get the summary. I don't want to filter it further upstream because the presence of the error will be useful in resolving #51.

@simonrobb 👍

Note, the following code was not possible due to Flow flagging it as an error:

const traces = _traces.filter(item => !(item instanceof Error)).map(getTraceSummary);

[simonrobb]

Agreed. At the least, if it's possible for there to be Error objects present, the parameter type should be annotated like you described, getTraceSummaries(_traces: (Trace | Error)[]): TraceSummaries.