• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

letsencrypt / boulder / 10904
66%

Build:
DEFAULT BRANCH: master
Ran 11 Jul 2019 05:55PM UTC
Jobs 1
Files 95
Run time 19s
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

11 Jul 2019 05:43PM UTC coverage: 61.358% (+0.004%) from 61.354%
10904

push

travis-ci

cpu
Fix FasterGetOrderForNames and add tests. (#4331)

This rolls forward #4326 after it was reverted in #4328.

Resolves https://github.com/letsencrypt/boulder/issues/4329

The older query didn't have a `LIMIT 1` so it was returning multiple results,
but gorp's `SelectOne` was okay with multiple results when the selection was
going into an `int64`. When I changed this to a `struct` in #4326, gorp started
producing errors.

For this bug to manifest, an account needs to create an order, then fail
validation, twice in a row for a given domain name, then create an order once
more for the same domain name - that third request will fail because there are
multiple orders in the orderFqdnSets table for that domain.

Note that the bug condition doesn't happen when an account does three successful
issuances in a row, because finalizing an order (that is, issuing a certificate
for it) deletes the row in orderFqdnSets. Failing an authorization does not
delete the row in orderFqdnSets. I believe this was an intentional design
decision because an authorization can participate in many orders, and those
orders can have many other authorizations, so computing the updated state of
all those orders would be expensive (remember, order state is not persisted in
the DB but is calculated dynamically based on the authorizations it contains).

This wasn't detected in integration tests because we don't have any tests that
fail validation for the same domain multiple times. I filed an issue for an
integration test that would have incidentally caught this:
https://github.com/letsencrypt/boulder/issues/4332. There's also a more specific
test case in #4331.

11312 of 18436 relevant lines covered (61.36%)

0.68 hits per line

Jobs
ID Job ID Ran Files Coverage
7 10904.7 (RUN="coverage" CONTAINER="netaccess") 11 Jul 2019 05:55PM UTC 0
61.36
Travis Job 10904.7
Source Files on build 10904
Detailed source file information is not available for this build.
  • Back to Repo
  • Travis Build #10904
  • 74699486 on github
  • Prev Build on master (#10900)
  • Next Build on master (#10906)
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc