letsencrypt / letsencrypt/boulder
Switch to async finalize if CAA rechecking or CT submission takes too long
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 5.8k
- Forks
- 649
- Avg merge
- 3d 23h
- Merged PRs (30d)
- 24
Description
We tried to turn on async finalize for everything, and there were too many clients that broke, so we had to turn it off.
We can try a middle ground, though: switching to async finalize when finalize is going to take a long time. We've discussed two possible variants of this:
- Set a short-ish initial timeout for finalize, and switch to async if that timeout is reached. We'd base this timeout on the current 95%ile or something like that.
- Immediately switch to async finalize if the order requires any CAA rechecking.
We should do some logs/metrics analysis to pick one of these strategies, then implement it. We can probably reuse the existing AsyncFinalize feature flag, which is currently only enabled in Staging.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by analyzing logs and metrics for finalize operations involving CAA rechecking and CT submission. Compare the proposed initial-timeout and immediate-CAA-recheck strategies, then determine which should use the existing AsyncFinalize feature flag. Done means the selected strategy is implemented and its behavior is validated for affected orders.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- backend, security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100