Deferred from #6 (review-findings-of-review-findings pass), flagged for triage before GA.
Where
MarkMonitorClient.EnrollCertificateAsync, the dedup-hit branch (around markmonitor-caplugin/Client/MarkMonitorClient.cs:604):
_logger.LogWarning(
"An identical enrollment for subject {Subject} was already submitted in the last {Minutes} minute(s) - awaiting that result instead of creating a duplicate order",
subject, RecentEnrollmentWindow.TotalMinutes);
return await existing.Tcs.Task;
Problem
This is a regression from the dedup-cache rework in #6. The log line records the subject and the
window, but not the CARequestID of the in-flight/just-completed order this call is being folded
into. When troubleshooting a "why did I only get one order for two submissions" report, there's
currently no way to correlate the dedup-hit log line with the actual order it resolved to without
also having the original enrollment's own log lines to hand.
Suggested fix
Await existing.Tcs.Task first (or thread the eventual EnrollmentResult back into the log call)
so the log line can include the resolved CARequestID.
Deferred from #6 (review-findings-of-review-findings pass), flagged for triage before GA.
Where
MarkMonitorClient.EnrollCertificateAsync, the dedup-hit branch (aroundmarkmonitor-caplugin/Client/MarkMonitorClient.cs:604):Problem
This is a regression from the dedup-cache rework in #6. The log line records the subject and the
window, but not the
CARequestIDof the in-flight/just-completed order this call is being foldedinto. When troubleshooting a "why did I only get one order for two submissions" report, there's
currently no way to correlate the dedup-hit log line with the actual order it resolved to without
also having the original enrollment's own log lines to hand.
Suggested fix
Await
existing.Tcs.Taskfirst (or thread the eventualEnrollmentResultback into the log call)so the log line can include the resolved
CARequestID.