Exception: empty collection can't be reduced

[f-f]

This happened when I deleted a certificate secret - to add more subdomains to it - and expected that kubernetes-letsencrypt would recreate it:

Exception in thread "Thread-26398" java.lang.UnsupportedOperationException: java.lang.UnsupportedOperationException: Empty collection can't be reduced.
	at sun.reflect.GeneratedConstructorAccessor54.newInstance(Unknown Source)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
	at java.util.concurrent.ForkJoinTask.getThrowableException(ForkJoinTask.java:593)
	at java.util.concurrent.ForkJoinTask.reportException(ForkJoinTask.java:677)
	at java.util.concurrent.ForkJoinTask.invoke(ForkJoinTask.java:735)
	at java.util.stream.ForEachOps$ForEachOp.evaluateParallel(ForEachOps.java:160)
	at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateParallel(ForEachOps.java:174)
	at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:233)
	at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
	at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:583)
	at in.tazj.k8s.letsencrypt.acme.CertificateRequestHandler.requestCertificate(CertificateRequestHandler.kt:41)
	at in.tazj.k8s.letsencrypt.kubernetes.ServiceManager.handleCertificateRequest(ServiceManager.kt:64)
	at in.tazj.k8s.letsencrypt.kubernetes.ServiceManager.access$handleCertificateRequest(ServiceManager.kt:20)
	at in.tazj.k8s.letsencrypt.kubernetes.ServiceManager$reconcileService$1.run(ServiceManager.kt:45)
	at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.UnsupportedOperationException: Empty collection can't be reduced.
	at in.tazj.k8s.letsencrypt.acme.CloudDnsResponder.findMatchingZone(CloudDnsResponder.kt:123)
	at in.tazj.k8s.letsencrypt.acme.CloudDnsResponder.updateCloudDnsRecord(CloudDnsResponder.kt:55)
	at in.tazj.k8s.letsencrypt.acme.CloudDnsResponder.addChallengeRecord(CloudDnsResponder.kt:26)
	at in.tazj.k8s.letsencrypt.acme.CertificateRequestHandler.prepareDnsChallenge(CertificateRequestHandler.kt:176)
	at in.tazj.k8s.letsencrypt.acme.CertificateRequestHandler.authorizeDomain(CertificateRequestHandler.kt:77)
	at in.tazj.k8s.letsencrypt.acme.CertificateRequestHandler.access$authorizeDomain(CertificateRequestHandler.kt:27)
	at in.tazj.k8s.letsencrypt.acme.CertificateRequestHandler$requestCertificate$1.accept(CertificateRequestHandler.kt:41)
	at in.tazj.k8s.letsencrypt.acme.CertificateRequestHandler$requestCertificate$1.accept(CertificateRequestHandler.kt:27)
	at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
	at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
	at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
	at java.util.stream.ForEachOps$ForEachTask.compute(ForEachOps.java:291)
	at java.util.concurrent.CountedCompleter.exec(CountedCompleter.java:731)
	at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
	at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056)
	at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)
	at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157) 

[f-f]

But I would like to add that, before this occurred, kubernetes-letsencrypt has been running in production for months without a single hiccup! So thank you for the good work :) 👏

[f-f]

Reasoning about the bug: looks like it happens here, where an empty List<Zone> is being reduced.

Would it be meaningful to just return null if the collection is empty? (I have a very vague idea about how the DNS challenge works, but not details that allow me to easily make sense of the business logic)

[f-f]

Update: as already identified in #72, this error leads to the misbehaviour reported there (too many currently pending authz) - so the two bugs are different but indeed linked.

[tazjin]

@f-f Interesting, thanks for looking into it a bit!

The "currently pending authz" issue should've been resolved by the change LE did on their side (i.e. automatically recycling authorisations) which required - according to their announcement - no client-side changes as the service simply returns the existing authorisation.

Did you see that one recently, too?

Would it be meaningful to just return null if the collection is empty?

It'd be the empty Option variant instead of null, but yes!

[f-f]

Did you see that one recently, too?

Yep, this morning I deleted and recreated the controller, and started getting #72.
I just applied the workaround listed there (deleting the letzencrypt-keypair secret), and I started getting this again.

[f-f]

Actually, I think this condition is being triggered by a configuration mistake of us - basically I'm trying to get a certificate for the wrong DNS (however it shouldn't fail this badly, as in the same certificate request I have some domains for which the DNS is correct).

[tazjin]

however it shouldn't fail this badly

Agreed! I've put in a PR that will add the relevant check to prevent it from throwing an unnecessary exception here.

[f-f]

Awesome, thank you! 👏