Existing release stopped working unexpectedly with NullPointerException about docker-it-scala

[giftig]

The offending method seems to be:

  override def listImages()(implicit ec: ExecutionContext): Future[Set[String]] = {
    Future(client.listImagesCmd().exec().asScala.flatMap(_.getRepoTags).toSet)
}

And then it leads into flatMap, which implies _.getRepoTags is being operated on a _ which is null. Looks like executing the command in the underlying DockerClient isn't working, and is somehow returning a null. Perhaps this bug would be more properly filed with dockerjava (or at least the part which pertains to the dockerjava implementation)

[giftig]

Incidentally if you'd like to reproduce my exact scenario, it's open source:

git clone https://github.com/giftig/flippy.git
cd flippy
sed -i -E 's/@Ignore//g' src/test/scala/com/xantoria/flippy/db/RedisBackendSpec.scala
mvn test

[viktortnk]

Hi @giftig

Unfortunately I don't know why it happens. I used series of 0.9 milestone releases with Spotify executor in our company projects and it worked. Maybe it is something with your build or conflicting dependency.

If latter, maybe you can try exclude spotify docker-client dependency shipped with library and include it's shaded version.

I will try to reproduce it with your code later

[jamesma]

I encountered into NullPointerException when executing ITs too, traced to this line of code (same as above):

override def listImages()(implicit ec: ExecutionContext): Future[Set[String]] = {
    Future(client.listImagesCmd().exec().asScala.flatMap(_.getRepoTags).toSet)
}

So it turns out that my docker host has dangling images, i.e. images with no repo tags <none>. I removed the dangling images from my docker host and the ITs run as normal without NPE. This does seem to suggest that it's due to the bug in the above method that getRepoTags returns null and causes the NPE.

[giftig]

Hmm, thanks @jamesma, I'll try cleaning up dangling images and running my tests again.

[giftig]

Alas, I still get a NullPointerException. When I get chance I'll try it in a completely fresh environment, but clearly there's a pretty nasty bug in that method if it makes image lookup so fragile. Can't really blame that one on whisk, though, so I'll go raise a bug with docker-java when I have a moment. I'd be interested in figuring out what the NoClassDefErrors with the spotify driver are about though, since that'd at least get around the issue by using the alternative driver.

[giftig]

Ah, sorry, just re-read your comment after some caffeine. In this case it would seem getRepoTags returning null is not a bug, since the underlying library is java, it just needs to be handled. I believe some of my dangling images were in use and couldn't be removed, so I'm probably still suffering from the same problem.

Should be a simple enough fix so I'll try patching it myself and submitting a pull request if I get a spare moment.

[giftig]

I got as far as cloning and compiling the library and going to do the patch but discovered the latest HEAD has the fix I was going to do.

          .flatMap(img => Option(img.getRepoTags).getOrElse(Array()))

Seems it's been fixed. I'll upgrade to RC1. Thanks.