MongoDB collection.find(whatever).first() can return null

SonarCloud generates a false positive when processing MongoDB collection.find(whatever).first(), because it assumes the return cannot be null.

  • versions used SonarCloud
  • minimal code sample to reproduce (with analysis parameter, and potential instructions to compile).
			Bson whereQuery = and(eq("uuid", uuid), exists("deleted", false)); // Any query will work
			final Document user = users.find(whereQuery).first();
			if (user != null) {

Hi,

Welcome to the community!

To make sure, is this Java?

 
Ann

Yes. Thanks.

Hello Daniel,

Can you please help us detail a bit more the issue by giving a bit more info:

  • What is the rule ID which reports a FP in your case?
  • Can you position the exact location of the FP?
  • What is the fully qualified name of the types you are using?

I tried to reproduce the issue with the following code (removing all code which would not be required), but I’m not getting any issue, so I guess I might miss something:

package org.foo;

import com.mongodb.client.MongoCollection;
import org.bson.Document;
import org.bson.conversions.Bson;

public class A {
  void foo(MongoCollection<Document> collection, Bson query) {
    Document user = collection.find(query).first();
    if (user != null) {
      doSomething();
    }
  }

  static void doSomething() { }
}

Thanks in advance,
Michael

I’m seeing this false positive too in my project.

When I try your example Michael I see the error go away. However if you invert the null check the error appears. “user” can be null and what if you need to “doSomething()” if its null. Sonar says to change the condition so that is does not always evaluate to false.

The “first()” method is annotated with Nullable, what are we missing here?

squid:S2583

EDIT:
Looking over other posts it looks like mongodb Nullable isn’t in the list of:

Hey @Cameron_Boyer,

Happy New Year!

The order of the null-check should not have any impact, because this should be handled correctly by our engine. On my machine, with the very same example, it does not change anything.

Thanks a lot for pointing this out. It allowed me to realize what was missing! The root cause of the issue is indeed tied to the com.mongodb.lang.Nullable annotation.

Looking at its code, it uses the JSR-305 annotation javax.annotation.Nonnull(when = When.MAYBE) as meta-annotation (and with the awfully-counterintuitive notation When.MAYBE). This use case is handled correctly by our engine, at the condition that the jar of JSR-305 is provided has dependency to the analysis!

In my test-project, I was using Guava, which provides the jar by transitivity… making issues disappear because the semantic of the mongodb annotation was correctly deduced. When exludiing the jar, the FPs now appears.

Now, regarding the fix, I created the following ticket to add the annotation to the whitelist: SONARJAVA-3654.

On your side (probably also apply to @Daniel_Greening ), and while you are waiting for the fix to be shipped, a workaround is to make sure that the JSR-305 jar is provided for the analysis.

Cheers,
Michael

1 Like

Wow, great to see such a detailed explanation :smiley:. Thank you for your help!

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.