letsencrypt / boulder / 10740 / 6
66%
master: 66%

DEFAULT BRANCH: master
Ran
Files 95
Run time 4s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 60.946%. Remained the same
RUN="coverage" CONTAINER="netaccess"

cron

travis-ci

rolandshoemaker 
RA: fix suberror identifier bug in CAA recheck. (#4259)

In the RA's recheckCAA function we loop through a list of *core.Authorizations, dispatching each to a Go routine that checks CAA for the authz and writes an error to a results channel.

Later, we iterate the same *core.Authorization list and read errors from the channel. If we get a non-nil error, then the current iteration's *core.Authorization is used as the identifier for the suberror created with the non-nil error.

This is a flawed approach and relies on the scheduling of recheck goroutines matching the iteration of the authorizations. When the goroutines write error results to the channel in an order that doesn't match the loop over the authorizations the RA will construct a suberror with the wrong identifier. This manifests as making the TestRecheckCAAFail unit test appear flaky, because it specifically checks the expected identifiers in the returned subproblems.

The fix involves writing both the checked authorization and the error result to the results channel. Later instead of iterating the authorizations we just read the correct number of results from the channel and use the attached authorization from the result when constructing a suberror.

Resolves #4248

Take away lessons:

Write unit tests and always verify expected values!
Always investigate flaky unit tests! Sometimes there's a real bug and not just a subpar test :-)

11375 of 18664 relevant lines covered (60.95%)

0.68 hits per line

Source Files on job 10740.6 (RUN="coverage" CONTAINER="netaccess")