Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Revert "SA: improve performance of GetOrderForNames. (#4326)" #4328

Merged
merged 1 commit into from
Jul 9, 2019

Conversation

jsha
Copy link
Contributor

@jsha jsha commented Jul 9, 2019

This reverts commit 9fa3607.

This commit can cause "gorp: multiple rows returned for: ..." under certain situations.

@jsha jsha requested a review from a team as a code owner July 9, 2019 20:33
@jsha jsha merged commit 2131065 into master Jul 9, 2019
@jsha jsha deleted the revert-fastergetorderfornames branch July 9, 2019 21:40
jsha added a commit that referenced this pull request Jul 11, 2019
This rolls forward #4326 after it was reverted in #4328.
jsha added a commit that referenced this pull request Jul 11, 2019
This rolls forward #4326 after it was reverted in #4328.
cpu pushed a commit that referenced this pull request Jul 11, 2019
This rolls forward #4326 after it was reverted in #4328.

Resolves #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:
#4332. There's also a more specific
test case in #4331.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants