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

WFE: Two changes to NewRegistration key-value rate limits #7258

Merged
merged 4 commits into from
Jan 23, 2024

Conversation

beautifulentropy
Copy link
Member

@beautifulentropy beautifulentropy commented Jan 11, 2024

Make NewRegistration more consistent with the implementation in NewOrder (#7201):

  • Construct transactions just once,
  • use batched spending instead of multiple spend calls, and
  • do not attempt a refund for requests that fail due to RateLimit errors.

Part of #5545

@beautifulentropy beautifulentropy requested a review from a team as a code owner January 11, 2024 22:18
@beautifulentropy beautifulentropy changed the title WFE: Only refund NewRegistration key-value limits after check completion WFE: Fix two issues with key-value rate limit refunds Jan 11, 2024
@beautifulentropy beautifulentropy changed the title WFE: Fix two issues with key-value rate limit refunds WFE: Fix two issues with NewRegistration key-value rate limit refunds Jan 11, 2024
pgporada
pgporada previously approved these changes Jan 12, 2024
@pgporada pgporada requested a review from a team January 12, 2024 16:19
wfe2/wfe.go Outdated Show resolved Hide resolved
wfe2/wfe.go Show resolved Hide resolved
@beautifulentropy beautifulentropy changed the title WFE: Fix two issues with NewRegistration key-value rate limit refunds WFE: Two changes to NewRegistration key-value rate limits Jan 17, 2024
@beautifulentropy beautifulentropy force-pushed the refund-after-check-completion branch 2 times, most recently from 9d21e51 to 5d19c16 Compare January 17, 2024 19:29
Copy link
Contributor

@aarongable aarongable left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM with one optional improvement.

defer func() {
if !newRegistrationSuccessful {
go wfe.refundNewAccountLimits(ctx, ip)
if !newRegistrationSuccessful && !errIsRateLimit {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know you didn't touch the newRegistrationSuccessful bool in this PR, so feel free to ignore me, but could this become

if err != nil && !errors.Is(err, berrors.RateLimit) {

? Rather than carrying around these two bools, I think the conditional can be computed here from variables we already have access to.

@beautifulentropy beautifulentropy merged commit 21044c5 into main Jan 23, 2024
18 checks passed
@beautifulentropy beautifulentropy deleted the refund-after-check-completion branch January 23, 2024 17:09
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.

3 participants