Prevent parallel validations

[rolandshoemaker]

Since it'll trigger parallel challenge/authorization updates which can cause 500's because of gorp optimistic locking errors.

[rolandshoemaker]

I think the easiest way to implement this would be to hold an in-memory map of authorization IDs that are currently being validated.

[rolandshoemaker]

Possible solution: https://github.com/letsencrypt/boulder/compare/prevent-parallel-validation?expand=1

[jsha]

This only works if you assume there's only ever one RA. I think a more robust approach would be for the RA to update the database to set the status of the challenge to "validating" before making a validation attempt, and refuse to re-attempt validation for stuff that's already validating.

[rolandshoemaker]

Ah yup, good point. I was trying to avoid having to actually touch the database but that looks like it's the only real solution that supports a multi-RA deployment 😕.

[aarongable]

I don't believe that parallel validations will cause 500s anymore, because we do validation in the background. If a client makes two requests to validate the same challenge in rapid succession, we will kick off two goroutines to do those checks. Presumably both checks will succeed, so we'll make two requests to the SA's FinalizeAuthorization2 method. One will succeed, the other will fail due to the "WHERE status = pending" clause. The failure will be audit logged but not result in a 500.

So I'm not sure it's worth expending effort on this anymore?