Potential: concurrent DCV TXT cleanup may race on a shared IDomainValidator #33

Scope

DCV-enabled builds only (SUPPORTS_DCV, the v2.x line). No impact on v1.x / non-DCV builds. Found during review of #20 (commit 9caf0ff). Unverified risk, not a reproduced failure.

Observation

DCV TXT cleanup was changed from sequential to concurrent: Task.WhenAll(stagedValidations.Select(CleanupOneStagedValidationAsync)) at CERTInextCAPlugin.cs:2138 (finally block) and :1888 (CleanupPartialStagingAsync). The comment at :1886 states the operations are independent with "no shared mutable state".

That is not guaranteed. The validator is resolved per domain (DomainValidatorFactory.ResolveDomainValidator(domain, "dns-01"), :2017), and a factory may return the same validator instance, or one backed by the same provider client, for domains in one zone (the in-repo test factories return a single shared instance). The IDomainValidator contract does not promise concurrent-call safety.

Risk

For a UCC order with many SANs in one zone, N CleanupValidation calls run at once against one provider plugin. If that plugin keeps per-call state (for example a last-record-id cache) or the provider rate-limits (HTTP 429), some deletes fail. Failures are only logged as Warnings, so orphaned _emsign-validation TXT records can remain.

Suggested fix

Either bound concurrency (a small SemaphoreSlim, or group by resolved validator instance and run each group sequentially), or confirm the supported DNS provider plugins are thread-safe and record that assumption in the comment. The original motivation (bounding aggregate cleanup time to DcvTimeoutMinutes) still needs to hold.